DRT-PBFT: A Novel PBFT-Optimized Consensus Algorithm for Blockchain Based on Dynamic Reputation Tree

Abstract

While the practical Byzantine fault tolerance (PBFT) consensus algorithm provides excellent theoretical fault tolerance, its performance in practical blockchain applications is often constrained by high communication overhead, especially in scenarios with limited node resources and high mobility, such as Vehicular Ad hoc Networks (VANETs). To address these blockchain-specific limitations without sacrificing the fundamental safety guarantees against arbitrary Byzantine failures, this paper proposes a novel PBFT-optimized consensus algorithm based on a dynamic reputation tree (DRT-PBFT). First, to address the issue of limited storage resources, we propose a block synchronization method based on differentiated storage of reputation values. The lower-reputation nodes retain only “micro-blocks” that contain essential information of the complete block, while the higher-reputation nodes store and synchronize complete blocks, significantly reducing the storage overhead. Second, on the basis of the reputation values, we construct a tree communication topology from the leaf node layer in a bottom-up manner. Messages are transmitted from multiple child nodes to their parent node, resolving the problem of a single message source in the tree structure. Additionally, we optimize the consensus process, reducing the number of mutual communications between nodes to a linear level. Finally, to address the problem of malicious nodes in the tree structure, we introduce a dynamic reconstruction mechanism for the reputation tree. When child node messages are inconsistent, the parent node splits the child nodes to mitigate the influence of malicious nodes, enhancing both the security and scalability of the consensus process. The experimental results show that, compared with typical improved PBFT algorithms, the proposed algorithm improves the average throughput by 34.1% and reduces the average latency by 27.4%. Moreover, compared with the full replication block synchronization method, the differentiated storage method reduces the storage overhead by 26.3%, making it potentially more suitable for large-scale VANET scenarios.

1. Introduction

Blockchain is a distributed ledger technology where data is stored in blocks and linked into a chain via hash functions, ensuring data integrity and immutability. In recent years, blockchain, as the underlying technology of Bitcoin, has received extensive research attention. While its application in domains like healthcare [1], energy management [2], and transportation [3,4] shows promise for supporting Industry 4.0, the transition from theoretical proposals to widespread industrial adoption remains a significant challenge due to several concrete issues [5,6]. These challenges include the efficiency and scalability of consensus algorithms, security concerns, and compatibility with existing systems. Although blockchain is not a one-size-fits-all solution, it offers specific advantages for applications that require tamper-proof auditing and decentralized trust. As a critical component of blockchain systems, consensus algorithms address the challenge of achieving state consistency in distributed systems, that is, how to ensure data consistency in environments where nodes lack inherent trust relationships and may exhibit Byzantine faults (i.e., arbitrary malicious behaviors) [7,8]. Therefore, designing efficient, scalable, and secure consensus algorithms is crucial for the application of blockchain technology.

In different blockchain scenarios, different consensus algorithms are typically employed. In public blockchains, commonly used consensus algorithms include proof of work (PoW) [9], proof of stake (PoS) [10], and delegated proof of stake (DPoS) [11]. The PoW consensus algorithm offers probabilistic safety under the assumption that the majority of network hash power is controlled by honest nodes. Here, probabilistic safety refers to probabilistic finality, which guarantees that all honest nodes will eventually agree on a unique and consistent transaction history. However, it suffers from low efficiency in terms of transaction throughput and latency. Bitcoin, which uses the PoW mechanism, typically has a throughput of only 7 transactions per second (TPS) and consumes a large amount of computational resources. The PoS consensus algorithm addresses the resource waste and low efficiency of PoW. However, compared to PoW, it offers weaker resistance to double-spending attacks in cryptocurrencies. Furthermore, in cryptocurrency implementations, the probability of being selected as a validator is proportional to the number of coins and the time the coins have been held. This concentration of consensus rights results in a lower degree of decentralization in the network’s control and governance. The DPoS consensus algorithm introduces a delegation mechanism where token holders vote for delegates (or witnesses) to validate blocks on their behalf, making it more decentralized than PoS in terms of the number of entities competing for validation. This is because in DPoS, the block validation task is delegated to a limited number of nodes, and token holders vote for their preferred validators to perform this task on their behalf. However, the direct participation of nodes in voting is relatively low since only the elected delegates typically participate in the consensus process. Additionally, the election mechanism cannot effectively address malicious delegated nodes in a timely manner. In private blockchains, the replication and fault tolerance (Raft) algorithm [12] is typically employed. The Raft algorithm provides high efficiency and low communication complexity (the number of mutual communications between nodes) for fail-safe nodes; however, it cannot withstand Byzantine nodes that exhibit arbitrary or malicious behaviors, such as sending conflicting information to different nodes, delaying messages, or failing to respond. On the other hand, consortium blockchains, which lie between public blockchains and private blockchains, offer more controllable node numbers and states compared to public blockchains, offering better protection of private user data through encryption. In particular, consortium blockchains distribute control and governance over the nodes in a distributed system among a predefined group of organizations, offering a more decentralized model of administration compared to private blockchains, which are typically governed by a single entity. This balance of decentralization and control makes them a preferred choice for many enterprise-level blockchain applications.

PBFT consensus algorithm [13] is commonly used in consortium blockchain scenarios. Operating under the Byzantine failure model, where nodes can exhibit arbitrary malicious behaviors (e.g., sending conflicting information), PBFT guarantees safety and liveness provided that the number of faulty nodes f satisfies the condition 3f + 1 ≤ N (N denotes the number of nodes). It addresses the high complexity problem of the original Byzantine fault tolerance (BFT) algorithm [14] and ensures immediate consistency under synchronous communication assumptions. In addition, compared with other consensus algorithms, PBFT does not rely on tokens and consumes fewer computational resources. However, in practical applications, the scalability of PBFT becomes increasingly problematic, because the communication complexity of PBFT is $O(N^2)$. As the blockchain network scales, this results in a significant increase in communication overhead, making the algorithm’s performance unable to meet practical application requirements. On the other hand, in traditional blockchain architectures that commonly adopt a full-replication data model, full nodes that participate in consensus and maintain the ledger are required to store the complete block history. This requirement leads to a significant increase in system storage overhead, posing a burden on nodes with limited storage resources.

In recent years, researchers have optimized the PBFT algorithm from different perspectives. However, approaches relying on node selection mechanisms (e.g., Direction 1) typically assume that past performance can predict future behavior, differing from the arbitrary Byzantine failure model of standard BFT. These works can be described as follows.

Direction 1: Reducing the number of consensus nodes. Liu et al. [15] introduced a prototype of an efficient PBFT consensus algorithm based on credit grouping, which classifies nodes into primary nodes, consensus nodes (responsible for validating blocks), and observer nodes (responsible for monitoring but not validating) through an optimized three-way quicksort algorithm. By restricting consensus to primary and consensus nodes, the participating nodes are minimized, thereby enhancing efficiency. Xu et al. [16] proposed a framework for a PBFT algorithm for vehicular networks, where a scoring mechanism is used to assess node performance. Higher-scoring nodes are selected as consensus nodes that participate in the full consensus process including block packaging, pre-prepare, prepare and commit stages, while lower-scoring nodes are designated as candidate nodes that only receive consensus results (the key summary information of the agreed block without complete transaction data). Candidate nodes are excluded from the interactive communication of the core consensus stages, and only store the lightweight consensus results instead of the complete blocks. In addition, node scores are dynamically updated in each consensus round, which effectively enhances node dynamism—the ability of the vehicular network to dynamically adjust the composition of consensus and candidate node sets according to the real-time performance of nodes. Zhang et al. [17] proposed a theoretical model of a node selection method based on a genetic algorithm and designed an adaptation function on the basis of node consensus behavior and the genetic algorithm. By continuously iterating, they selected nodes with excellent consensus-related metrics (including consensus participation rate, transaction verification accuracy, and message response timeliness) to participate in the core consensus process, which reduces the probability of consensus failures caused by low-performance nodes and thus improves the efficiency of consensus and block generation speed. Gan et al. [18] utilized clustering algorithms to group nodes and selected consensus nodes by calculating their geographic location values and reputation values, thus enhancing the consensus efficiency within the group. The optimization direction of the above studies mainly focuses on decreasing the number of nodes participating in the core consensus process. This reduces the number of nodes maintaining a complete ledger copy, which brings higher consensus efficiency and lower overheads yet inevitably reduces the number of Byzantine nodes the system can tolerate. This approach, to some extent, lowers communication overhead and enhances the algorithm’s scalability. However, this efficiency is achieved at the cost of sacrificing some degree of decentralization, without considering optimizations from the perspective of the consensus process and message exchange patterns. Moreover, introducing new node selection methods introduces additional computational burdens. For example, Zhang et al. [17] and Gan et al. [18] used genetic algorithms and clustering algorithms to evaluate nodes, which, in large-scale networks, leads to high computational overhead due to frequent iterations and clustering.

To address the quadratic communication complexity of PBFT mentioned earlier, another major research direction focuses on optimizing the communication topology, since the original PBFT used the full-mesh interactive topology where all nodes communicate with each other, with a detailed analysis of the optimized tree-based communication topology and its limitations presented in Section 2.2.

Direction 2: Optimizing the consensus process and communication topology. Yin et al. [19] proposed HotStuff, a protocol demonstrated in a large-scale lab setting, which reduces the communication complexity to O(n) by using star topology and threshold signature technique, which significantly improves the consensus efficiency (the transaction throughput and consensus latency performance of the consensus process). However, the star topology suffers from defects such as overloading of the primary node and single point of failure. For this reason, the researchers further introduced a tree topology to optimize the consensus process. Li et al. [20] proposed a Byzantine fault tolerant consensus algorithm based on a perfect binary tree communication topology. The communication topology is optimized into a perfect binary tree based on the node’s reputation value, thereby lowering the algorithm’s communication complexity. Additionally, by introducing a rotating leader and pipelining mechanisms into the consensus process, the consensus efficiency is improved. Jiang et al. [21] divided nodes into distinct subnets based on a tree topology in their experimental evaluation. Consensus messages are transmitted from the root node to the child nodes in a top-down manner, and by utilizing the tree structure, conversion from global consensus to local consensus is achieved, reducing communication overhead. A feedback mechanism was proposed to mitigate the influence of Byzantine nodes on the tree structure. The above studies optimize the communication topology and consensus process of the original PBFT algorithm using tree structures, significantly reducing the communication overhead. However, the following key problems of the tree structure are not effectively solved: (1) Child node messages come from a single parent node, which lacks comparability. (2) If a nonleaf node is a malicious node, it affects all its child nodes, resulting in a lack of dynamic adjustability. To address the problem of malicious nodes, Li et al. [20] replaced the malicious node with its sibling node, while Jiang et al. [21] used cross-layer communication to suppress the influence of malicious nodes; that is, the child node directly communicated with the parent node of the malicious node. However, the above studies still placed the malicious node in a fixed position in the tree structure, and potential security risks still exist, without considering the removal or adjustment of the malicious node position. Moreover, the above studies did not consider optimizing the block synchronization method to reduce the storage overhead.

To address these issues, a PBFT-optimized consensus algorithm based on a dynamic reputation tree (DRT-PBFT) is proposed in this paper. The main contributions of this paper are as follows.

(1)

To address the structural limitations of existing tree-based consensus, we propose a novel bottom-up reputation tree structure for the first time. Nodes are matched with sibling nodes based on the results of reputation ranking, and the tree structure is constructed in a bottom-up manner. High-reputation nodes are responsible for verifying and aggregating messages from sibling nodes, and they are promoted to parent nodes once the verification is successful. Moreover, the consensus direction is optimized from the traditional top-down approach to a bottom-up approach, with messages transmitted from leaf nodes to the root node. This ensures that each node has multiple message sources, addressing the problem of a single message source in traditional tree structures.

(2)

We further introduce a pioneering dynamic reconstruction mechanism that enhances the Byzantine fault tolerance of the reputation tree. When there is inconsistency in the messages of child nodes, the parent node splits the child nodes, and the split child nodes send messages separately to the root node. By dynamically adjusting the reputation tree, the impact of malicious nodes on the tree structure is reduced. Moreover, malicious nodes are penalized in terms of reputation and will be moved to the right subtree in the next round of reputation tree construction, addressing the problem of fixed positions for malicious nodes and the lack of penalties in traditional tree structures, thereby improving the stability of the algorithm.

(3)

A reputation-based block synchronization mechanism is designed, which leverages differentiated storage of reputation values. In this mechanism, for nodes with lower reputation values, only ‘micro-blocks’ containing key information of the complete block are synchronized, while complete blocks are synchronized by nodes with higher reputation values. Through reputation ranking and the dynamic reconstruction mechanism of the reputation tree, the nodes synchronizing “micro-blocks” are dynamically adjusted, so that each node maintains a mixed chain of “micro-blocks” and complete blocks, effectively reducing the system’s storage overhead.

It is important to clarify the relationship between the reputation model and the Byzantine fault tolerance (BFT) assumptions. Traditional BFT guarantees safety under the strict theoretical assumption that nodes may deviate arbitrarily and unpredictably at any time. While this assumption holds for the underlying consensus logic, treating all nodes with equal suspicion in practical, resource-constrained environments leads to prohibitive overhead and latency. Therefore, this work does not relax the strict BFT assumptions; instead, it introduces a reputation model as an auxiliary mechanism to optimize performance. The core consensus process of DRT-PBFT still relies on cryptographic signatures and the classic “3f + 1” voting threshold to ensure correctness, thereby tolerating arbitrary faults. The reputation mechanism serves to identify potential Byzantine nodes based on historical data to proactively structure the communication topology and reduce overhead, while the dynamic reconstruction mechanism ensures that even if a node behaves arbitrarily and unpredictably (violating reputation predictions), the system can isolate it and reach consensus. Thus, the algorithm optimizes PBFT for efficiency without sacrificing its fundamental fault tolerance properties.

The remainder of this paper is organized as follows. Section 2 elaborates on the technical background of the classic PBFT algorithm and tree communication topology, and analyzes their inherent limitations in practical applications that motivate the design of our optimized algorithm. Section 3 presents the proposed DRT-PBFT algorithm in detail, including the system model and assumptions, the design of the reputation evaluation model, the construction method of the bottom-up reputation tree, the complete consensus process, the dynamic reconstruction mechanism for the reputation tree, and the differentiated storage strategy based on reputation values. Section 4 conducts a rigorous theoretical analysis of DRT-PBFT, focusing on its Byzantine fault tolerance security and the reduction in communication overhead compared with traditional PBFT and its improved algorithms. Section 5 describes the experimental setup, and verifies the performance of DRT-PBFT from multiple dimensions including node reputation changes, throughput, latency, malicious node transfer, storage overhead and network stability under stress conditions, with detailed comparative analysis against typical PBFT-based consensus algorithms. Finally, Section 6 summarizes the main research work and experimental conclusions of this paper, and outlines the limitations of the current study and the key directions for future research optimization.

2. Background and Related Works

This section provides the technical background for the PBFT algorithm and the tree communication topology, analyzing their inherent limitations to motivate the proposed DRT-PBFT algorithm.

2.1. Problems of the PBFT Algorithm

To achieve consistency and fault tolerance in a distributed system, the Replicated State Machine (RSM) model is often employed. In this model, multiple nodes start from the same initial state and execute the same sequence of commands, ensuring they reach identical final states. The core challenge for an RSM is to establish a total order on these commands across all replicas, a task known as consensus. In this context, a distributed ledger acts as the log recording the sequence of state transitions (e.g., transactions), while the distributed state machine executes these transitions to reach a consistent state. Therefore, blockchain systems are a specific application of the distributed state machine model. PBFT algorithm is a classic solution that provides this consensus service, where all nodes involved in the consensus participate to ensure data consistency. The algorithm operates with continuous view numbers, with only one primary node in each view, while the other nodes serve as replica nodes to validate the block information generated by the primary node. If the total number of nodes is N, the algorithm can tolerate at most f Byzantine faulty full nodes. For the algorithm to function properly, the relationship between N and f must satisfy 3f + 1 ≤ N.

The PBFT consensus process and block synchronization, shown in Figure 1, consist of five stages: request, pre-prepare, prepare, commit, and reply. Let node 0 be the primary node, and nodes 1, 2, and 3 be replica nodes, with node 3 being a Byzantine node that disrupts the consensus of other nodes through actions such as crashing or sending incorrect messages. Through analysis, the following issues can be observed in Figure 1.

(1)

High communication complexity. In the five-stage consensus of PBFT, the prepare and commit phases require nodes to mutually validate the legitimacy and consistency of the consensus messages and digital signatures sent by each other, resulting in a quadratic growth of messages as the network scales. This characteristic is the core reason for its communication complexity of O(N²). Taking the four nodes in Figure 1 as an example, a complete consensus process results in at least 22 message transmissions. For blockchain systems oriented to high-mobility scenarios such as VANETs, increasing replica nodes is a necessary design choice to meet the demands of decentralization, enhance Byzantine fault tolerance and improve network coverage robustness against node mobility. However, when the scenario is scaled to a large node network, the communication overhead grows quadratically as the node count increases, severely impacting the blockchain system throughput and latency.

(2)

High storage overhead. Before the consensus begins in Figure 1, in the public chain environment utilizing the PBFT algorithm, each node locally stores the historical blockchain data. When consensus begins, primary node 0 collects the messages sent by clients. After verification, the primary node enters the pre-prepare phase, where the transactions are packed into blocks, and the pre-prepare message is sent to nodes 1, 2, and 3 for validation. Each node verifies the block transactions by checking the validity of transaction digital signatures and the syntactic and logical legitimacy of transactions and eliminating duplicate transactions, and after the commit phase, the local blockchain is updated by appending the most recently agreed-upon block. In the context of blockchain, the full replication ledger model commonly adopted in practical applications leads to significant storage challenges, which is further exacerbated by the large number of consensus nodes required for PBFT to satisfy its Byzantine fault tolerance and decentralization requirements. In blockchain applications that typically employ a full replication ledger model to ensure data integrity, each node is required to store the entire block history, which imposes significant storage burdens and limits the system scalability with network expansion. This model dictates that all replica nodes first reach consensus on the next block via the PBFT protocol, and then the updated complete ledger history is fully replicated across all participating nodes during the subsequent block synchronization phase. While techniques such as checkpointing allow nodes to prune historical data to manage cumulative overhead, the continuous growth of the blockchain in the classic full-replication storage model leads to substantial data redundancy. Consequently, the storage burden increases significantly over time.

2.2. Problems of Tree Communication Topology

To optimize the communication complexity of the PBFT algorithm, researchers have proposed adopting a tree communication topology, with a typical tree structure shown in Figure 2.

In Figure 2, the root node is the primary node, and the remaining nodes are replica nodes. The root node is responsible for receiving and replying to request messages from clients and then packages the messages and passes them down to child nodes. Each child node receives messages from its parent node, appends its own signature after verification, and continues passing the message down until the leaf nodes. Finally, the leaf nodes forward the messages with signatures from all nodes to the root node, which validates them and replies to the client, completing the consensus. Through tree topology consensus, nodes only need to communicate with their parent and child nodes, effectively reducing the communication complexity of the PBFT algorithm. However, the tree structure also introduces the following new problems.

(1)

Uniqueness of message sources. As shown in Figure 2, a node’s message has only one source, that is, the parent node. When the parent node is a malicious node, the node cannot verify the correctness of the received message through comparison. Moreover, in a typical tree structure, the root node holds authority. If the root node is malicious, the algorithm may reach an incorrect consensus due to the uniqueness of the message source.

(2)

Low stability and dynamics. In Figure 2, a malicious nonleaf node affects all its child nodes, causing the root node to fail in collecting the required number of consistent messages, thus affecting consensus stability. Moreover, the typical tree structure lacks measures to penalize malicious nodes. Even if a node behaves maliciously, the malicious node remains in a fixed position, and lacks dynamic adjustability.

Regarding the consensus algorithms and optimization schemes discussed in this paper and the cited references, their maturity levels are classified as follows: Bitcoin (PoW) [9] is a commercially used system; Raft [12], HotStuff [19] are lab demonstrations, while PBFT [13] is additionally implemented in Hyperledger Fabric prototypes; and the remaining proposed improvements [15,16,17,18,20,21] are unvalidated research proposals.

3. The Proposed DRT-PBFT Algorithm

3.1. System Model and Assumptions

We consider a consortium blockchain scenario where nodes may exhibit Byzantine failures (arbitrary malicious behaviors). While the proposed DRT-PBFT algorithm utilizes a reputation model based on historical performance to optimize the communication topology, the underlying consensus protocol still abides by the classic PBFT’s 3f + 1 fault tolerance constraint, 2/3 voting threshold and cryptographic signature verification, thus retaining the complete Byzantine fault tolerance capability. The reputation mechanism serves as an auxiliary optimization to enhance efficiency and construct a reputation tree—we select high-reputation nodes as the root and near-root non-leaf nodes to fundamentally reduce the probability of Byzantine nodes occupying the core tree positions discussed in Section 2.2, and the dynamic reconstruction mechanism will be triggered to split and isolate the affected subtrees if any Byzantine node is found near the root; this optimization only refines the tree communication topology, rather than redefining the failure model from arbitrary to predictable. Taking the system with 9 nodes as an example, the overall algorithm model, which consists of 4 steps, is shown in Figure 3.

Step 1: Reputation ranking. Before each round of consensus, the reputation model calculates the reputation values of each node and ranks them accordingly. As shown in Figure 3, the reputation model ranks nodes 1 to 9, with node 1 having the highest reputation and node 9 having the lowest reputation.

Step 2: Constructing the reputation tree. First, the root node plays a crucial role in consensus stability, so the node with the highest reputation is selected as the root. Second, the remaining nodes are paired as sibling nodes on the basis of their reputation values. The node with the higher reputation on the left reduces its level index to become the parent node. Finally, this process continues, and the level index is continuously reduced until the root node is reached. In Figure 3, node 1, which has the highest reputation, is chosen as the root node, and the remaining nodes 2 to 9 are leaf nodes. According to the reputation values, nodes 2 and 3, nodes 4 and 5, nodes 6 and 7, and nodes 8 and 9 form sibling pairs. Nodes 2, 4, 6, and 8 are their respective parent nodes. Eventually, nodes 2 and 6 reduce their index levels to become the left and right children of the root node.

Step 3: DRT-PBFT consensus. Unlike traditional tree structure consensus, the direction of communication in DRT-PBFT consensus is bottom-up, meaning that the messages are sourced from the child nodes and have comparability. Specifically, all child node messages are generated based on the same original client request, carrying a unified global request ID and data digest, enabling the parent node to cross-verify and compare the content, signature and digest of multiple child node messages. In Figure 3, the client first sends request messages to root node 1 and leaf nodes 2 to 9. Afterward, the consensus-related messages and validation information are transmitted upward from the leaf nodes to the root node, through which the network reaches a global consensus.

Although the client sends request messages to both the root node and all leaf nodes in this step, which seems to increase the number of communication targets compared with traditional tree topology consensus (Figure 2), this design is a core security optimization to solve the problem of single message source and lack of original data verification in traditional tree structures, and the potential additional communication overhead and latency are effectively offset by multiple mechanisms, with no significant negative impact on the overall system performance.

Step 4: Differentiated storage In the reputation tree with N nodes, the number of leaf nodes is $N_{leaf}=N-1$. For the f nodes with lower reputation values, which correspond to the $⌊N_{leaf}/3⌋$ nodes on the right side of the leaf node layer in the reputation tree, only “micro-blocks” containing complete block holder information are synchronized. The complete blocks are synchronized by the N-f nodes with higher reputation values, corresponding to the $N_{leaf}-⌊N_{leaf}/3⌋$ nodes on the left side of the leaf node layer in the reputation tree. In Figure 3, nodes 8 and 9 on the right side of the leaf node layer (with lower reputation values) perform “micro-blocks” synchronization. In contrast, nodes 2 to 7 on the left side (with higher reputation values) conduct complete block synchronization.

The core purpose of storing micro-blocks is to strike a balance between reducing the storage overhead of the blockchain system and preserving the characteristics of the decentralized ledger. Micro-blocks retain the core key information of complete blocks (block header + core block body information), on the basis of which lightweight basic blockchain services such as transaction integrity verification can be provided. Directly excluding low-reputation nodes would cause multiple losses to the blockchain network in terms of its decentralization features, fault-tolerance security, and network robustness.

3.2. Reputation Evaluation Model

The node reputation value directly affects its position in the reputation tree. To accurately evaluate node behaviour during consensus and reduce the probability of malicious nodes being root nodes, a reputation evaluation model is designed. The reputation evaluation indicators presented in this paper are classified into four major types: direct reputation, indirect reputation, node malicious degree, and historical reputation. Among them, the direct reputation value includes node contribution and node reliability, while the indirect reputation value includes node activity and the node incentive value. The detailed content of the reputation model is as follows.

Definition 1. 

Node contribution $C\_con$. Node contribution means that if a node participates in the consensus, it is considered to have contributed to the consensus and can receive corresponding contribution rewards. The contribution of node i is determined using the following formula:

$$C\_{con}_i=\left\{\begin{array}{cc}{e}^{\left(-{\displaystyle \frac{1}{p_1}}\right)},& p_1\ne 0\\ 0,& p_1=0\end{array}\right.$$

(1)

where $C\_co{n}_i$ represents the contribution of node i, $p_1$ is the consensus participation rate, as shown in Formula (2), $Num\_c_i$ represents the number of times a node participates in consensus, and $Num\_c$ represents the total number of consensus processes between two reputation updates.

$$p_1={\displaystyle \frac{Num\_c_i}{Num\_c}}$$

(2)

Formula (1) designs the node contribution calculation by adapting to the operational features of consortium blockchains and the high dynamicity of VANETs. It takes the consensus participation rate as the core indicator to incentivize nodes to participate actively and avoid free-riding, which ensures a sufficient valid node base for the reputation tree and consensus. The calculation is lightweight with only simple counting, fitting the resource-constrained VANET on-board nodes and reducing the overhead of reputation evaluation. In addition, the participation statistics cycle is consistent with the reputation update cycle (5 consensus rounds) to balance data timeliness and system overhead, and nodes with zero participation get no reward, which helps screen out invalid nodes and lay a foundation for the construction of the reputation tree and the operation of the dynamic reconstruction mechanism.

Definition 2. 

Node reliability $C\_rel$. Node reliability refers to the number of times a node successfully reaches correct consensus and synchronize blocks among the times it participates in consensus. A higher reliability indicates that the node is actively and honestly participating in consensus. The reliability of node i is calculated by the following formula:

$$C\_re{l}_i={\displaystyle \frac{Num\_s_i}{Num\_c_i}}$$

(3)

where $C\_re{l}_i$ represents the reliability of node i, and $Num\_s_i$ is the number of times node i successfully reaches the correct consensus and synchronizes the blocks. Through node reliability, honest nodes can further receive reliability rewards in addition to the contribution reward.

Definition 3. 

Node activity $C\_act$. Node activity is used to evaluate the activity status of nodes, and certain activity rewards are given according to the role the node plays. If a node serves as a primary node multiple times, it means that the node has accumulated more reputation through the reputation model and has higher activity. The activity of node i is determined using the following formula:

$$C\_ac{t}_i={\displaystyle \frac{\alpha \times Num\_p_i+(1-\alpha )\times Num\_n_i}{e\times (Num\_c+Num\_c_i)}}$$

(4)

where $C\_ac{t}_i$ is the activity of node i, $Num\_p_i$ represents the number of times node i acts as the primary node, while $Num\_n_i$ is the number of times node i acts as the replica node. $\alpha$ is the weight, and $\alpha >0.5$, thus, the primary node will receive more activity rewards. Where e is a reputation index normalization adjustment constant with a value range of 0 < e < 1.

Definition 4. 

Node incentive value $C\_enc$. The node incentive value is designed to motivate nodes with lower reputation rankings to actively join the consensus, and the level of incentive is related to the node’s own reputation ranking. The incentive value of node i is determined using the following formula:

$$C\_en{c}_i={\displaystyle \frac{C\_ran{k}_i}{e\times (n+C\_ran{k}_i)}}$$

(5)

where $C\_en{c}_i$ represents the incentive value of node i, $C\_ran{k}_i$ is the reputation ranking of node i, and n is the total number of nodes. The node with the top reputation ranking receives the lowest incentive value, while the node with the lowest reputation ranking receives the highest incentive value.

Definition 5. 

Node malicious degree $C\_mal$. The reputation model divides node malicious behaviors into five categories, as shown in

Table 1. Malicious behavior categories.

Behavior Types	Description
Crash Fault Type	Node Does Not Send or Receive Any Messages
Message Tampering Type	Node Tampering with Consensus Messages
Delay Response Type	Node Intentionally Delay Sending Messages
Duplicate Response Type	Node Sending a Large Number of Duplicate Messages to the Same Node
Contradictory Response Type	Node Sending Contradictory Messages to Different Nodes

. By detecting node behaviors, nodes that meet the behavior in Table 1 are considered malicious, receive a malicious degree penalty, and have their reputation value reduced. The malicious degree of node i is determined using the following formula:

$$C\_ma{l}_i=e\times Num\_m_i$$

(6)

where $C\_ma{l}_i$ represents the malicious degree of node i, and $e$ is a constant. $Num\_m_i$ is a penalty factor that represents the malicious degree of node i in the consensus, and is numerically equal to the number of malicious acts of node i between two reputation updates.

Definition 6. 

Node total reward $C\_rew$. The total reward for the node includes direct and indirect reputation values. The total reward of node i is determined using the following formula:

$$C\_re{w}_i=C\_co{n}_i\times C\_re{l}_i+C\_ac{t}_i\times C\_en{c}_i+1$$

(7)

where $C\_re{w}_i$ represents the total reward of node i, and $C\_co{n}_i$ and $C\_re{l}_i$ are the contribution and reliability of node i, which are the node’s direct reputation values. $C\_ac{t}_i$ and $C\_en{c}_i$ represent the activity and incentive value of node i, which are the node’s indirect reputation values. The addition of 1 is to avoid mathematical calculation singularities and prevent the total reward from being zero when all indicators of a node are zero, which would render subsequent reputation updates invalid.

Definition 7. 

Reputation update. The reputation update function, as shown in Formula (8), consists of three parts: the node total reward, the node malicious degree, and the node historical reputation value.

$$C\_ne{w}_i=C\_ol{d}_i+C\_re{w}_i-C\_ma{l}_i$$

(8)

where  $C\_ne{w}_i$  represents the updated reputation value of node i, $C\_ol{d}_i$  is the historical reputation value, $C\_re{w}_i$  is the total reward earned by node i, and  $C\_ma{l}_i$  is the malicious degree.

It is worth mentioning that the reputation update result must be jointly verified by all nodes in the network; it takes effect only after confirmation by more than 2/3 of the nodes. Any attempt to collusively raise a reputation score would conflict with the records of honest nodes, making reputation tampering difficult to achieve. Moreover, the construction of the reputation tree on the basis of the reputation model enhances the dynamism of the tree structure, with each node’s position in the tree changing according to its reputation value.

3.3. Construction of a Bottom-Up Reputation Tree

This paper optimizes the communication between nodes using a tree structure, and in response to the problems of message source uniqueness and root node authority in the tree structure discussed in Section 2.2, a bottom-up constructed reputation tree structure is proposed. Figure 4 demonstrates the process of reputation tree construction, and the detailed steps are as follows.

Step 1: The reputation model ranks the nodes by reputation and assigns serial numbers. As shown in Figure 4, nodes 1 to 10 are assigned numbers after reputation ranking, with node 1 having the highest reputation value and node 10 having the lowest.

Step 2: The node with the top reputation ranking is selected as the root node, and the remaining nodes are paired with their immediately lower ranked neighbor nodes to form sibling nodes and become the leaf node layer of the reputation tree. When the number of nodes cannot form a complete binary tree, the remaining nodes serve as candidate nodes. When a leaf node behaves maliciously, the candidate nodes can obtain the opportunity to participate in the reputation tree through reputation ranking. As shown in Figure 4, node 1 becomes the root node, while nodes 2 and 3, nodes 4 and 5, nodes 6 and 7, and nodes 8 and 9 are paired as sibling nodes to form the leaf node layer, with node 10 serving as a candidate node.

Step 3: In each sibling node group, the reputation value of the left subtree node is always higher than that of the right subtree node, and the consensus requires a more reliable node to lead. Therefore, first, the layer index of the left subtree node is lowered to make it the parent node, and it also becomes the highest nonleaf node layer. As shown in Figure 4, nodes 2, 4, 6, and 8 become the parent nodes of each sibling node group. Second, in the new layer, each node continues to pair with another node at the same level to form sibling nodes. As shown in Figure 4, nodes 2 and 4 and nodes 6 and 8 are paired as sibling nodes. Finally, this process is repeated until they become the child nodes of the root node. Since the candidate node has a low reputation value, it will not participate in the reputation tree consensus but will communicate directly with the root node. As shown in Figure 4, nodes 2 and 6 become child nodes of the root node, and candidate node 10 communicates directly with the root node. When the root node fails, the left child node of the root node will take over the root node and become the temporary primary node.

As seen from the above process, entering the upper layer requires consistent messages between sibling nodes. This bottom-up structure solves the problem of unique message sources in traditional tree structures, making the messages comparable. Essentially, all nodes are located at the leaf node layer, and even if malicious nodes exist, they affect only the voting in the leaf node layer, thus mitigating the impact on the tree structure. Moreover, each node only needs to communicate with its sibling nodes, significantly reducing the communication overhead of the algorithm. The reputation tree construction algorithm is shown in Algorithm 1.

Notably, to defend against Sybil attacks where malicious actors control multiple low-reputation leaf nodes to compromise the shared parent node (aggregation point), the parent node adopts a reputation-weight dual verification threshold (Section 3.2) for message aggregation: instead of only counting consistent messages, it requires the total reputation weight of sending nodes to account for over 50% of the total weight of all its child nodes. This invalidates the quantity advantage of low-reputation Sybil nodes, as their cumulative reputation weight is far insufficient to meet the threshold, thus preventing unfair influence on the parent node.

Algorithm 1. Reputation tree construction algorithm
Input: Cn (Node reputation sorting array)
Output: RTree (Reputation tree)
1:	Struct RTree: {Node, Left, Right, List[ ]} //Initialize the reputation tree structure
2:	$L\leftarrow ⌊lo{g}_2(len.Cn)+1⌋$ $j\leftarrow L$ $i\leftarrow 1$ //Initialize layer index, candidate node index, and incremental index
3:	while L > 2 do //Traversing each layer
4:	$sum\leftarrow 0$ $lt\leftarrow 1$ $--L$ //Initialize the count of layer nodes and array pointer lt, enters the parent node layer
5:	for L.sum ! = 2L−1 //The count of nodes in layer L is not full
6:	$RTree. Node\leftarrow Cn{[lt]}_L$ //Add nonleaf nodes
7:	$Cn{[lt]}_L. Left\leftarrow Cn{[lt]}_{L+1}$ $Cn{[lt]}_L. Right\leftarrow Cn{[lt+2^{i-1}]}_{L+1}$ //Assign child nodes to nonleaf nodes
8:	$RTree\leftarrow Cn{[lt]}_L$ //Store node information in the reputation tree
9:	sum++ lt = lt + 2i //Increase the count of layer nodes, and the lt pointer points to the next node to be allocated
10:	end for
11:	i++
12:	end while
13:	$Root\leftarrow Cn[0]$ $Root. Left\leftarrow Cn{[1]}_L$ $Root. Right\leftarrow Cn{[2^{L-2}+1]}_L$ //Add a root node and assign child nodes
14:	$Root.List[ ]\leftarrow Cn[2^{j-1},len.Cn-1]$ //Add a list of candidate nodes for the root node
15:	return RTree //Return the reputation tree

3.4. Consensus Process

The DRT-PBFT consensus process consists of five stages: request, pre-prepare, prepare, commit, and reply. In Figure 5, node 1 is the primary node, and nodes 2 to 9 are the replica nodes. The specific consensus process is as follows.

Step 1: Request stage: The client sends a request message $〈Request,tx,t,c,{\sigma }_c〉$ to root node 1 and leaf nodes 2 to 9, where tx is the transaction information, t is the timestamp, and c and ${\sigma }_c$ represent the client’s number and signature, respectively.

Step 2: Pre-prepare stage: After receiving the client’s request message, leaf nodes 2 to 9 will verify the validity of the transaction and the client’s signature. If valid, they will construct the pre-prepare message $<<Pre\text{-}Prepare,tx,t>{\sigma }_1,{\sigma }_2,\cdots ,{\sigma }_i>$ and interact with sibling nodes for validation, where ${\sigma }_i$ (i represents any node identifier) denotes the digital signature of a participating node, and the signatures are appended in the order of node validation completion and reputation tree layer propagation rather than the fixed order of node indices. i. If two sibling nodes receive and verify different transactions, they will first cross-verify against the client’s standardized global request to eliminate source data inconsistency; if the inconsistency persists, the sibling node pair fails the mutual validation, triggering the precondition for the reputation tree’s dynamic reconstruction mechanism. The parent node will split the inconsistent sibling nodes, which then send the pre-prepare message with their own signature and data digest directly to the root node for global verification. If the higher-reputation sibling node is malicious (e.g., tampering with transaction data, forging verification results), its malicious behavior will be detected by the sibling node’s cross-verification of signatures and digests, and the dynamic reconstruction mechanism will be immediately triggered to split the malicious node from the sibling pair. The malicious high-reputation node will be subject to the highest-level malicious degree penalty (per Definition 5 and Table 1) by the reputation model, with its reputation value sharply reduced, and the root node will ignore its invalid transaction data and conduct consensus verification based on the valid data of honest nodes. The pre-prepare message is transmitted starting from the leaf nodes. During transmission, nodes with higher reputations collect messages from sibling nodes. After verification, their signatures are appended to the pre-prepare message. Afterward, the layer index is reduced, and the node moves to the upper layer to continue collecting sibling node messages until it reaches the root node. In the pre-prepare stage of Figure 5, through transmission and collection of sibling node information, node 2² holds the valid signature information of nodes 2 to 5, while node 6² holds the valid signature information of nodes 6 to 9.

Step 3: Prepare stage: The root node receives the pre-prepare messages from child nodes 2² and 6², verifies the validity of the included node signatures, and compares them with the client transaction information it has received. If valid, the transaction is packaged into a block. The root node then constructs the prepare message $<<Prepare,v,h,d,t,\sigma >{\sigma }_1,{\sigma }_2,\cdots ,{\sigma }_i,B_{head}>$, where v is the view number, h is the block height, ensuring that all nodes reach consensus under the same view and block height, d represents the digest of the request message, i is the total number of valid signatures that satisfies i ≥ 2N/3 (the Byzantine fault tolerance requirement), and the signatures are appended in the order of reputation tree layer propagation and verification completion rather than the fixed node index order, $\sigma$ is the aggregated signature generated when node signatures surpass 2/3 of the total nodes, and B_head is the block header information. Essentially, nonleaf nodes are virtual hierarchical nodes, while actual replica nodes reside in the leaf node layer. Therefore, the root node directly forwards the prepare message to the leaf nodes.

Step 4: Commit stage: After receiving the prepare message, the leaf nodes will verify its validity and check if d and B_head match the original client request message locally. Upon passing the validation, the leaf nodes will construct a commit message $<<Commit,v,h,d,t>{\sigma }_1,{\sigma }_2,\cdots ,{\sigma }_i>$ and forward it to their sibling nodes, continuing the transmission upward to the root node.

Step 5: Reply stage: After the root node verifies the commit messages, it updates its local blockchain and sends a reply message to the client. The message content is $<Reply,v,h,t,c,r>\sigma$, where r represents the consensus result. Moreover, according to the node signature number, the complete block is sent to the leaf nodes ranked in the top $N_{leaf}-⌊N_{leaf}/3⌋$ in reputation, and the “micro-blocks” are sent to the leaf nodes ranked in the bottom $⌊N_{leaf}/3⌋$. Once the message is received, the leaf node updates the local blockchain, and the consensus is completed.

3.5. Dynamic Reconstruction for the Reputation Tree

To mitigate the influence of malicious nodes on the tree structure and enhance the dynamics of the reputation tree, this paper designs a dynamic reconstruction mechanism for the reputation tree.

In the reputation tree, the condition for entering the upper layer is that the child node messages are consistent. When the child node messages are inconsistent or a timeout occurs, the dynamic reconstruction mechanism of the reputation tree is triggered, as shown in Figure 6. First, assuming that node 7 is a malicious node, the messages received by nodes 6³ and 6² will be inconsistent. At this time, the node will split its child nodes, retaining only the subtree with consistent messages, while the sibling node group to which the malicious node belongs will be split into individual nodes. As shown in Figure 6, sibling nodes 6 and 7 are split into individual nodes, while the subtree with nodes 2² and 8³ as roots is retained. Second, after the child nodes are split, the tree structure transforms into a forest structure. The root nodes of each subtree and the individual nodes send messages to the primary node to continue the consensus. As shown in Figure 6, nodes 2², 8³, 6, and 7 each send messages to the primary node. Finally, after the consensus is complete, the reputation model punishes malicious nodes according to the penalty rules, and their reputation values are reduced. In the next round of reputation tree construction, malicious nodes are transferred to the right side of the leaf node layer. As shown in Figure 6, malicious node 7 will be penalized by a decrease in reputation. After reputation ranking, node 7 is at the last position. According to the construction rules of the reputation tree, node 7 is at the rightmost edge of the leaf node layer in the new reputation tree.

Through the dynamic reconstruction mechanism of the reputation tree, the impact of malicious nodes on the tree structure can be limited to the leaf node layer. Combined with the reputation model, malicious nodes are transferred to the right side of the leaf node layer, while honest nodes are stabilized on the left side of the leaf node layer by accumulating their own reputation values. Finally, in a reputation tree with $N_{leaf}$ leaf nodes and f malicious nodes, the $N_{leaf}-⌊N_{leaf}/3⌋$ nodes on the left side of the leaf node layer form an honest subtree. The number of honest nodes meets the consensus requirements, so the honest subtree can quickly reach a consensus, while the malicious nodes will be concentrated in the $⌊N_{leaf}/3⌋$ nodes on the right to form a malicious subtree, which is convenient for centralized control.

In addition to the handling of malicious child nodes, the dynamic reconstruction mechanism also supports the detection, recovery and orphaned child node reintegration for malicious or failed parent nodes, with the whole process following the reputation tree construction rules (Section 3.3) without additional overhead: (1) Detection of malicious/failed parent nodes: The child nodes detect abnormal behaviors of the parent node through cryptographic signature and message consistency verification (Section 3.4)—a failed parent node is identified by continuous message timeout and no response, while a malicious parent node is identified by sending tampered messages inconsistent with the root node’s standardized global request. (2) Initiation of dynamic reconstruction: Once detected, the dynamic reconstruction mechanism is triggered immediately, the malicious/failed parent node is isolated and removed from the reputation tree, and its child nodes are marked as orphaned nodes. (3) Election of new parent nodes: For the orphaned child node group, the node with the highest reputation value in the group is elected as the new parent node in accordance with the reputation ranking rule; if the reputation values of all orphaned nodes are too low, the candidate node (Section 3.3) bound to the reputation tree is selected as the new parent node. (4) Reintegration of orphaned child nodes: After the new parent node is elected, the orphaned child nodes rejoin the reputation tree according to the bottom-up construction rule of the reputation tree and continue to participate in message aggregation and upward transmission; if the new parent node election fails (e.g., no candidate nodes are available), the orphaned child nodes communicate directly with the root node to send consensus messages, which does not affect the normal progress of the global consensus.

3.6. Differentiated Storage Strategy

The full replication storage method of blockchain is limited in scenarios with constrained storage resources, such as in VANETs. In actual applications, not all nodes’ data can be accessed and utilized; thus, it is not necessary for all nodes to store data, but data storage must be able to guarantee the decentralized storage characteristics of blockchain. In response, this paper proposes a block synchronization method based on differentiated storage of reputation values.

Differentiated storage means that during the block synchronization stage, considering the reliability of nodes, the f nodes with the lowest reputation rankings do not synchronize the complete block but only synchronize the “micro-blocks” that retain the key information of the complete block. The complete block is synchronized by the top N-f nodes in the reputation ranking. The structure of “micro-blocks” is shown in Figure 7, where the block header contains the following fields: Pre-blockhash, Timestamp, Height, Merkle_Root and Hash. The Pre-blockhash field is the hash of the previous block, Timestamp stores the time when the block was created, Merkle_Root is used for transaction integrity verification, and the Height and Hash fields are used to identify the specific position of the block in the chain. The block body contains the following fields: Pubkey&Sign_List and Node_List. The Pubkey&Sign_List field stores the public keys and signatures of the nodes that store the complete block, while Node_List stores the numbers of these nodes.

In a complete block, the block body stores a large amount of transaction data, which is the main factor for high storage overhead, while in “micro-blocks”, the block body only stores the node public key, signature, and number information. When requesting a complete block or auditing data, the correctness of the Merkle_Root is verified, the node number information is used to locate the node that stores the complete block, and the public key and signature information is used to verify the identity of the requesting node. To clarify the security properties, the ‘micro-block’ retains the data integrity guarantee of the full block via the Merkle Root, preventing attackers from tampering with data. Even if only a subset of nodes stores the full data, nodes with ‘micro-blocks’ must retrieve the complete block from the high-reputation nodes listed in the Node_List. This mechanism ensures that any inconsistency is detected during the Merkle Root verification process, maintaining security despite differentiated storage. Compared with storing large amounts of transaction data, storing node information in the block body requires less storage overhead and prevents nodes with low reputation from synchronizing empty blocks, causing data loss.

The “micro-blocks” are constructed by the primary node during the commit stage and sent to the corresponding nodes. Combined with the reputation model, the nodes that synchronize “micro-blocks” are not fixed, and each node maintains a mixed chain of “micro-blocks” and complete blocks. A comparison between full replication storage and differentiated storage is shown in Figure 8. In Figure 8, all nodes in the full replication storage have complete blocks, while the differentiated storage generates “micro-blocks” in each round of consensus, and the nodes that synchronize the “micro-blocks” are constantly changing as the reputation model is dynamically adjusted. For example, suppose four rounds of consensus are performed in Figure 8. In the first round, nodes 1, 2, 4, and 5 have high reputation values. According to the differentiated storage rule, node 3 with a low reputation value synchronizes the “micro-blocks”, and the remaining nodes synchronize the complete block. In the second round, after evaluation by the reputation model, node 2 has a lower reputation value; therefore, it synchronizes the “micro-blocks”.

Low-reputation nodes storing only micro-blocks can still verify blockchain state integrity via the Merkle Root embedded in micro-blocks and the built-in list of high-reputation nodes with complete block storage: they request transaction data from multiple such high-reputation nodes and perform cross-verification based on the Merkle Root, achieving lightweight validation without the full blockchain state. This differentiated storage design does not create a static, insecure two-tier system: node reputation values are dynamically updated (Section 3.2), so low-reputation nodes can upgrade to store complete blocks through honest consensus participation, while high-reputation nodes are restricted by the 3f + 1 fault tolerance constraint (Section 2.1) and dynamic reconstruction mechanism (Section 3.5), with malicious nodes limited to no more than 1/3 and isolated in a timely manner. In addition, the generation of micro-blocks requires signature verification by more than 2/3 of all nodes (Section 3.4), ensuring the authenticity of the data stored by low-reputation nodes and maintaining the decentralization and security of the entire system.

4. Algorithm Analysis

4.1. Security Analysis

The use of a reputation model in this algorithm is primarily an optimization strategy to reduce communication complexity and improve consensus efficiency. It is worth noting that the algorithm does not rely solely on the predictability of node behavior to achieve safety. On the contrary, the security of DRT-PBFT is maintained even when nodes behave arbitrarily and unpredictably. The “3f + 1” condition and the 2/3 voting requirement inherent in the PBFT protocol remain the final guarantees of consensus correctness. Notably, all optimized mechanisms (reputation tree, dynamic reconstruction, and differentiated storage) are auxiliary and do not alter the core fault-tolerance logic of PBFT: the total number of nodes N still satisfies N ≥ 3f + 1 (with f being the maximum number of Byzantine nodes tolerated), and the 2/3 voting threshold is strictly enforced in all key consensus phases (pre-prepare, prepare, commit), where aggregated signatures and global consensus verification are only valid when confirmed by more than 2/3 of honest nodes. Mathematically, when N ≥ 3f + 1, the number of honest nodes is at least 2f + 1, which is more than 2/3 of the total nodes and sufficient to reach a valid consensus. This core constraint is fully validated in the subsequent special case analysis (malicious root node, malicious child nodes, etc.) in this section, proving that DRT-PBFT has the same resilience to Byzantine nodes as the original PBFT protocol, and even enhances the practical fault-tolerance effect by isolating malicious nodes through dynamic reconstruction. The reputation mechanism assists in structuring the network to minimize the probability of reaching consensus timeouts, but the dynamic reconstruction mechanism (as described in Section 3.5) is specifically designed to handle arbitrary message inconsistencies (Byzantine faults) regardless of whether the node’s reputation predicted such behavior. Regarding the overhead, the verification of reputation values is piggybacked onto the standard DRT-PBFT consensus phases (e.g., within the Reply message), incurring only linear communication complexity O(N). Since reputation updates are performed periodically (e.g., every 5 consensus rounds), this additional O(N) overhead is negligible compared to the O(N²) communication complexity reduction achieved by the tree topology. Therefore, the system retains the essential Byzantine fault tolerance property while enhancing performance.

To demonstrate the security and superiority of the reputation tree proposed in this paper, it is compared with the ordinary binary tree structure and the perfect binary tree structure proposed in [20]. The three tree structures are shown in Figure 9. Under the assumption that malicious nodes account for no more than 1/3 of the total nodes, the following three special cases are discussed and analyzed: the root node is malicious, the child nodes of the root node are malicious, and the root node and child nodes are all malicious.

Case 1: The root node is malicious. For both the ordinary binary tree and the perfect binary tree, the root node is authoritative. If the root node is a malicious node, it will cause consensus failure or trigger a view change by sending error messages or crashing. Conversely, the reputation tree is based on power decentralization, which distributes the authority of the root node to other nodes. In the request stage, the leaf nodes have the original request data of the client. Even if the root node can tamper with the request message, the leaf nodes can compare it with the original data in the prepare stage to make a judgment. Therefore, for the reputation tree, a malicious root node triggers only a view change without causing a false consensus.

Case 2: The child nodes of the root node are malicious. As the most critical nonleaf nodes, the child nodes of the root node have a crucial impact on the consensus, which can be divided into two cases: some of the child nodes are malicious, and all child nodes are malicious.

(1) Some of the child nodes are malicious: As shown in Figure 9, in an ordinary binary tree, assume that the right child node of the root node is malicious; then, for the entire tree structure, the right subtree will either become invalid or reach a false consensus. In the best case, assuming that the root node can receive consistent messages from the left subtree, for a binary tree with L layers, the left subtree of the root contains $2^{L-1}-1$ nodes, so the root node has at most $2^{L-1}$ consistent messages, and the total number of nodes is $2^L-1$. When L > 1, the relationship between the count of consistent messages and the total nodes satisfies Formula (9). Therefore, for an ordinary binary tree, consensus cannot be reached when some of the child nodes behave maliciously.

$$2^{L-1}<{\displaystyle \frac{2}{3}}(2^L-1)$$

(9)

In a perfect binary tree, sibling nodes can communicate with each other. Even if the right child of the root node is a malicious node, its child node can obtain the correct message from the left child of the root node and thus reach a correct consensus. For the reputation tree, the right child of the root node is malicious, which is actually node 6⁴ in Figure 9. In the process of message transmission, it is necessary to append its own signature. Even if the node can tamper with tx information, it cannot crack or forge the private key signature $\sigma$ of its sibling node. Therefore, it will trigger the dynamic reconstruction mechanism of the reputation tree and can still reach a correct consensus.

(2) All child nodes are malicious: In this case, for both the ordinary binary tree and the perfect binary tree, since both the left and right children of the root node are malicious, the lower layer nodes will lose the correct message source. Although malicious nodes cannot forge the primary node private key signature, they can interfere by not forwarding messages, causing consensus failure or view change. In the reputation tree, all child nodes are malicious, which are nodes 2⁴ and 6⁴ in Figure 9. From (1) of case 2, the dynamic reconstruction mechanism of the reputation tree will be triggered. In the reputation tree with L layers, the total number of nodes is $2^{L-1}+1$. Under the condition that the number of malicious nodes does not exceed 1/3 of the total number, the number of consistent messages Count owned by the root node always satisfies Formula (10), so a correct consensus can be reached.

$$Count\ge {\displaystyle \frac{2}{3}}(2^{L-1}+1)$$

(10)

Case 3: The root node and child nodes are all malicious. As shown in Figure 9, for ordinary binary trees and perfect binary trees, nodes 1 to 3 are all malicious nodes. The lower layer nodes lose all correct message sources, which eventually leads to consensus failure or view change. In the reputation tree, from (2) of case 2, the dynamic reconstruction mechanism will be triggered, and each node will send messages to the root node individually, even if the root node can tamper with and forge d, B_head and $\sigma$ in the prepare message. As seen from case 1, honest nodes will discover that the root node is behaving maliciously, which will trigger a view change but will not reach false consensus.

In summary, the comparative analysis demonstrates that the reputation tree proposed in this paper offers superior security in the aforementioned special cases compared to ordinary and perfect binary trees. The security comparison analysis of the three tree structures is shown in

Table 2. Special case security comparison.

Tree Structure	Malicious Node Cases
	Root Node	Some Child Nodes	All Child Nodes	Root Node and Child Nodes
Ordinary Binary Tree	Consensus Failure View Change	Consensus Failure	Consensus Failure View Change	Consensus Failure View Change
Perfect Binary Tree	Consensus Failure View Change	Consensus Success	Consensus Failure View Change	Consensus Failure View Change
Reputation Tree	View Change	Consensus Success	Consensus Success	View Change

.

4.2. Communication Overhead Analysis

Given that the size of message data is fixed, the number of message transmissions is the primary factor determining the actual communication overhead in real-world distributed systems. For this reason, we analyze the communication overhead of various consensus algorithms based on the number of message transmissions.

The communication overhead refers to the total number of message transmissions between nodes during a single consensus round. For the communication complexity, we define it as the order of growth of the total number of message transmissions with the increase in the total number of physical leaf nodes N (all replica nodes of DRT-PBFT are located in the leaf node layer, and non-leaf nodes are virtual aggregation nodes with no actual message transmission). The DRT-PBFT consensus algorithm uses a bottom-up reputation tree structure for optimization, dividing nodes into N/2 sibling node groups for point-to-point message interaction and aggregated upward transmission. It no longer requires all nodes to interact with each other, and the total number of message transmissions is linearly related to n. This section provides a quantitative of the total number of message transmissions for a single DRT-PBFT consensus round, the mathematical proof of linear complexity O(N), and a comparative calculation with the classic PBFT’s quadratic complexity O(N²). Moreover, a communication complexity analysis was performed on the PBFT algorithm based on a cooperative group (CG-PBFT) [15], the PBFT algorithm based on a sharding group (SG-PBFT) [16], the probability-based trading BFT algorithm (PBT-BFT) [20], and the sparse topology algorithm (STBFT) [21], and the results are shown in

Table 3. Communication complexity of each algorithm.

Algorithm	Communication Complexity
PBFT	O(N2)
CG-PBFT	O(N2)
SG-PBFT	O(N2)
STBFT	O(N2)
PBT-BFT	O(N)
DRT-PBFT	O(N)

.

Since the CG-PBFT and SG-PBFT algorithms restrict nodes from participating in consensus and do not consider optimizing the communication topology, their communication complexity is $O(N^2)$. Although the STBFT algorithm introduces a tree structure, it does not use the advantages of the tree structure to reach consensus, resulting in a communication complexity of $O(N^2)$. PBT-BFT and DRT-PBFT use tree structures and optimize the consensus process. Nodes only need to communicate with sibling nodes or parent nodes, effectively reducing the communication complexity of the algorithm.

5. Experimental Results and Analysis

To validate the efficiency of the DRT-PBFT algorithm, an experiment was conducted in an environment with an Intel (R) Core (TM) i7-13700HX processor, 16 GB of memory, and a Windows 11 system. The software environment consisted of Python 3.1 and PyCharm 2023. The experiment simulated node activity in a distributed system using multithreading, and the data generated during the consensus process were recorded through a log system. Considering that our research focus lies on the performance and scalability at the consensus algorithm level, factors such as physical mobility in VANETs and signal interference in complex electromagnetic environments are regarded as directions for future research. The experimental analysis focuses on six aspects: node reputation changes, throughput, latency, malicious node transfer, storage overhead, and “micro-block” proportion.

5.1. Node Reputation Changes

In the experiment, four nodes with different attributes were set: high reliability node (node 1), general reliability node (node 2), nonparticipating node (node 3), and malicious node (node 4). The reliability $C\_rel$ of node 1 is set to 1, and that of node 2 is set to 0.4. The initial reputation value of each node is 50, and 100 rounds of consensus are carried out. Malicious node 4 performs malicious acts in the 2nd and 14th reputation updates. The changes in the reputation of each node are shown in Figure 10.

As shown in Figure 10, nodes 1 and 2 have different reputation growth trends. The reputation model can distinguish nodes with different reliabilities. Node 3 is excluded from the consensus, and its reputation value remains unchanged. The second reputation update was conducted after the 10th round of consensus. Malicious node 4 was set to tamper with messages twice, and its reputation points were deducted according to the reputation penalty rules. Afterward, malicious node 4 maintained honest behavior and gradually improved its own reputation value. The 14th reputation update was conducted after the 70th round of consensus. Malicious node 4 was set to perform 5 tampering behaviors. The penalty factor caused the node to receive a greater degree of reputation penalty. The results show that the reputation evaluation model can distinguish nodes with different reliabilities and provide different degrees of rewards, while punishing malicious nodes accordingly.

The results in Figure 10 demonstrate that our reputation model can effectively differentiate nodes based on their reliability and behavior. This is crucial because by incentivizing high reliability nodes and penalizing malicious ones, the system can ensure that consensus tasks are more likely to be handled by stable and predictable nodes. This directly reduces the risk of consensus failure caused by malicious or unreliable nodes, which in turn minimizes resource wastage on redundant communications and retries. Moreover, in a high mobility environment, our model provides a dynamic mechanism to adapt to node churn and changing trust relationships, forming a foundation for a robust consensus system. Notably, the fluctuations of node 3 are not a flaw of the algorithm model, but a normal data performance of the simulation environment that aligns with the dynamic nature of VANETs, which reflects the reputation model’s capability for accurate perception and adaptive computing of nodes’ dynamic behaviors.

5.2. Throughput

Throughput indicates how many transactions a system can handle within a given time frame. It serves as a key metric for assessing algorithm performance and is typically measured in TPS. The corresponding formula is presented in Formula (11).

$$TPS={\displaystyle \frac{Coun{t}_{tx}}{\Delta t}}$$

(11)

where $Coun{t}_{tx}$ represents the total number of transactions, and $\Delta t$ is the time consumed to process the transactions. To verify the efficiency of the DRT-PBFT algorithm, we conduct a throughput comparison analysis with the PBFT algorithm, the PBT-BFT algorithm [20], and the STBFT algorithm [21]. The reasons for selecting these two algorithms are as follows. First, both PBT-BFT and STBFT, similar to our DRT-PBFT, utilize a tree structure to optimize the PBFT algorithm, thus sharing similarities in topology and consensus process. Second, these two algorithms are highly representative, as they respectively represent a probability-based trading BFT and a sparse topology-based BFT, embodying different optimization directions. The experiment was conducted with 5, 9, 17, 33, 65, 129, and 257 nodes, corresponding to 3-layer to 9-layer reputation trees, respectively. The results of each group of nodes are the average data of 20 tests, and the results are shown in Figure 11.

As shown in Figure 11, when the number of nodes increases, the throughput of the four algorithms tends to decrease, but the DRT-PBFT consistently achieves higher throughput compared to PBFT and STBFT. The PBFT algorithm has high communication complexity and requires all nodes to verify each other, resulting in low throughput. When the count of nodes exceeds 129, the PBFT algorithm remains at 35 TPS. The STBFT algorithm introduces a tree structure and divides the nodes into different tree layers. Compared with the PBFT algorithm, its throughput is significantly improved, but the tree structure is not used to further optimize the consensus process. The overall throughput falls short of the DRT-PBFT algorithm. The throughput of PBT-BFT is similar to that of DRT-PBFT. In the case of fewer nodes, the throughput exceeds that of DRT-PBFT because PBT-BFT limits the consensus of some nodes. However, in the case of numerous nodes, the tree structure of PBT-BFT is easily affected by malicious nodes, resulting in a rapid decrease in throughput. In contrast, DRT-PBFT effectively reduces the communication complexity and the influence of malicious nodes through the reputation tree and dynamic reconstruction mechanism, and the consensus efficiency is greatly enhanced. When the total number of nodes is 257, the throughput is increased by 20.2% compared with PBT-BFT, and the overall average throughput is increased by 160.7% compared with the original PBFT algorithm, and by 34.1% compared with STBFT, respectively.

It is worth noting that while the reduction in communication complexity offers greater benefits as NN grows, DRT-PBFT does not introduce additional overhead in small-scale scenarios. For instance, when N = 9, the throughput of DRT-PBFT remains competitive with PBFT. However, even at this small scale, the dynamic reconstruction mechanism provides superior resilience against malicious nodes compared to PBFT, making DRT-PBFT a more secure choice for VANETs regardless of the node density.

5.3. Latency

Latency indicates the duration from when the client sends a request to the completion of the transaction. Lower latency indicates faster transaction execution. The calculation formula is shown in Formula (12):

$$Latency=T_{reply}-T_{request}$$

(12)

where $T_{reply}$ is the time when the client receives the reply, and $T_{request}$ is the time when the request is sent. Under the same conditions as the throughput experiment, latency tests were conducted on the four algorithms, and the results are shown in Figure 12.

As shown in Figure 12, the latency of the four algorithms increases, but the latency of the DRT-PBFT algorithm increases at a lower rate, and its average latency is lower than that of the PBFT and STBFT algorithms. In PBFT, transactions need to be mutually verified between many nodes, resulting in high latency. The STBFT algorithm uses a tree structure to distribute the transaction verification process to each layer, effectively reducing the time required for transaction confirmation, but each layer of nodes still needs to interact with one another, and the overall latency is greater than that of DRT-PBFT. The latency of the PBT-BFT algorithm is similar to that of the DRT-PBFT algorithm when the number of nodes is small, but as the node count grows, the latency of the PBT-BFT algorithm is greater than that of the DRT-PBFT algorithm. In contrast, in the DRT-PBFT algorithm, which uses the reputation tree structure, transactions need to be verified only between sibling nodes at each layer, which significantly reduces latency. When the total number of nodes is 257, the latency is reduced by 22.4% compared with that of PBT-BFT, and the overall average latency is reduced by 52.9% compared with the original PBFT algorithm, and by 27.4% compared with STBFT.

Furthermore, we have also conducted comparisons with other algorithms from the related work, such as CG-PBFT and SG-PBFT. The results show that DRT-PBFT outperforms CG-PBFT and SG-PBFT in both throughput and latency, and DRT-PBFT also achieves lower storage overhead.

5.4. Malicious Node Transfer

To verify whether the dynamic reconstruction mechanism can effectively adjust the positions of malicious nodes, an experiment involving malicious node transfer was conducted. In the experiment, the total number of nodes is set to 9 nodes, which constitutes a 4-layer reputation tree. The count of malicious nodes is set to 2, and the initial reputation ranking is high, with a 90% probability of tampering with messages. The reputation ranking of malicious nodes after the reputation update is tracked and recorded, and the rank change trend of malicious nodes with the number of reputation updates is shown in Figure 13.

As shown in Figure 13, the rank change trend of the two malicious nodes with high initial rankings presents a clear characteristic of initial stability → gradual decline → sharp drop → falling to the bottom. Specifically, when the number of reputation updates is less than 3, the malicious nodes maintain a relatively stable ranking due to their high initial reputation, and are located at the core left position of the leaf node layer in the reputation tree. With the continuous progress of the consensus, the tampering behaviors of the malicious nodes are detected by the system, and the reputation model triggers a gradient penalty according to the number of malicious acts, leading to a sustained gradual decline in their rankings. At the 5th reputation update, the rankings of the two malicious nodes drop sharply to the 7th and 4th positions respectively, with their positions in the leaf node layer shifting significantly to the right, and the influence of malicious nodes on the core consensus is effectively weakened. When the number of reputation updates reaches 7, the malicious nodes suffer cumulative heavy penalties for multiple malicious behaviors, and their rankings plummet to the bottom of the whole network (the 7th and 8th positions of the leaf node layer). The above trend fully shows that the combination of the dynamic reconstruction mechanism and the reputation model can realize the gradient adjustment of the reputation ranking of malicious nodes: the malicious nodes are gradually driven from the core left position of the reputation tree to the rightmost edge of the leaf node layer with the increase in malicious acts, which not only effectively avoids the continuous interference of malicious nodes on the core consensus link, but also realizes the centralized control of malicious nodes in the reputation tree.

5.5. Storage Overhead and Micro-Block Proportion

To obtain the optimal f value for differentiated storage, we specifically discuss three aspects: system storage overhead, algorithm security, and algorithm feasibility.

Storage overhead model: Assuming that n indicates the total number of nodes, while f refers to the count of nodes synchronizing “micro-blocks”, and V is the average storage capacity of the complete block, the storage overhead required to store the complete block is determined using the following formula:

$$S_c=(n-f)\times V$$

(13)

where $S_c$ is the total storage overhead for storing the complete block. The storage overhead of “micro-blocks” is calculated by the following formula:

$$S_f=f\times k\times V$$

(14)

where $S_f$ is the total storage overhead for storing “micro-blocks”, $k$ is the storage ratio of the “micro-blocks” relative to the complete block, and $k<1$. Therefore, the total storage cost of the system is shown in Formula (15).

$$S_{total}=V\times \left[(n-f)+f\times k)\right]$$

(15)

Security model: Assuming that the number of Byzantine nodes is f, the security of the system is determined by the number of Byzantine nodes. The security can be represented by the following formula:

$$P_s={\displaystyle \frac{n-f}{n}}$$

(16)

when f increases, the security decreases, but the feasibility of the algorithm introduces a security threshold $P_{threshold}$, and the number of malicious nodes f must satisfy $f\le ⌊n/3⌋$. Under the conditions of n = 100, V = 10 KB, and k = 0.3, the changes in system storage overhead and security with the value of f are shown in Figure 14.

As shown in Figure 14, the system storage overhead and security both decrease as f increases. When f = n, the system storage overhead $S_{total}$ reaches the minimum, but the security $P_s$ also reaches the minimum. However, the feasibility of the algorithm can be satisfied only when $f\le ⌊n/3⌋$, at which point the security threshold $P_{threshold}\approx 0.67$. Therefore, after comprehensively considering the system storage overhead, algorithm security, and algorithm feasibility conditions, the optimal f value is $f=⌊n/3⌋$, which can ensure that the system achieves a better balance.

To verify whether differentiated storage and “micro-blocks” can effectively reduce system storage overhead, a block synchronization test was conducted. In the experiment, the count of transactions in a block was set to 10, and the total block data size in each round of consensus and the proportion of “micro-blocks” in the node’s local blockchain relative to all blocks were recorded. The results represent the average of 20 rounds of data. The storage overhead and “micro-block” proportion results are shown in Figure 15 and Figure 16.

As shown in Figure 15, as the scale of nodes increases, the total data size of the system also increases sharply, but the storage overhead of the full replication method is always greater than that of differential storage. This is because, in differential storage, not all nodes need to have complete data. Nodes with low reputation only need to synchronize “micro-blocks”, which effectively reduces the storage overhead of the system. Compared with the full replication method, the average storage overhead required for differential storage is reduced by 26.3%.

As shown in Figure 16, with a growing number of nodes, the proportion of “micro-blocks” relative to all blocks, i.e., the “micro-block” rate, fluctuates around 30%, which is essentially in line with the optimal f value. This is because the reputation model selects f nodes with low reputation values to synchronize “micro-blocks”, so that the system “micro-block” rate is around f.

5.6. Network Stability Under Stress Conditions

In realistic VANET environments, network dynamics such as packet loss and signal interference are inevitable, leading to unstable communication conditions. To evaluate the sensitivity of DRT-PBFT to these network stress factors, we extended our experiment to simulate network instability. We introduced packet loss rates of 0%, 5%, 10%, and 15% into the communication process to observe their impact on the consensus success rate.

As shown in

Table 4. Consensus success rate under different packet loss rates.

Algorithm	Consensus Success Rate (Packet Loss Rate 0%)	Consensus Success Rate (Packet Loss Rate 5%)	Consensus Success Rate (Packet Loss Rate 10%)	Consensus Success Rate (Packet Loss Rate 15%)
PBFT	98.5%	82.3%	54.7%	31.2%
STBFT	97.2%	89.6%	76.2%	48.5%
PBT-BFT	98.0%	91.5%	78.3%	52.1%
DRT-PBFT	99.3%	97.8%	95.2%	91.6%

, DRT-PBFT exhibits superior robustness compared to PBFT and STBFT. Under mild stress (5% loss), all algorithms maintain relatively high consensus success rates. However, as the packet loss rate increases to 10% and 15%, the performance of PBFT and STBFT declines sharply because their rigid structures are prone to timeouts when messages are lost. In contrast, DRT-PBFT maintains a consensus success rate of over 90% even at a 15% packet loss rate. This resilience is primarily attributed to the dynamic reconstruction mechanism: when network instability causes message inconsistencies or timeouts, the reputation tree dynamically splits the affected child nodes. This allows the honest subtrees to proceed with consensus without waiting for the lost packets, effectively isolating the impact of network stress. Furthermore, we evaluated the variations in throughput and latency under increasing packet loss rates. The results demonstrate that while all algorithms experience performance degradation, the reputation tree structure of DRT-PBFT maintains significantly higher throughput and lower latency compared to PBFT and STBFT. This confirms that the reputation tree remains robust and behaves sensibly even when messages are missing, as the dynamic reconstruction mechanism allows subtrees to continue consensus independently despite communication failures.”

6. Conclusions

This paper addresses the challenges of high communication and storage overhead faced by the PBFT consensus algorithm and proposes the DRT-PBFT consensus algorithm. First, we design a reputation tree structure based on the reputation evaluation model, optimize the consensus transmission direction in a bottom-up manner, and enable nodes to have multiple message sources. Second, we propose a dynamic reconstruction mechanism for the reputation tree to mitigate the influence of malicious nodes and dynamically adjust the position of malicious nodes in combination with the reputation model, thereby improving the dynamics of the reputation tree. Finally, we use differentiated storage to effectively alleviate the problem of high system storage overhead and improve the scalability of the algorithm. The results of experiments indicate that the DRT-PBFT consensus algorithm has better performance and lower storage overhead, demonstrating its algorithm-level potential for large-scale and highly dynamic VANETs.

It is important to note that the current experimental evaluation was conducted in a simulated single-machine, multithreaded environment. While this setup effectively validates the algorithm’s core logic and performance potential, it does not fully capture the real-world network dynamics of VANETs (e.g., network latency and packet loss), which is a limitation of our study. We acknowledge that the algorithm’s performance in real-world deployment may vary.

Future research will therefore focus on several key areas. First, we plan to deploy and test the algorithm in a more realistic distributed testbed or a cloud-based environment to better assess its performance under actual network conditions. Second, since the reputation model relies on fixed rules, it may be difficult for the model to adapt to dynamic and changing real scenarios, and the accuracy of reputation calculation and the ability to identify malicious nodes need to be further improved. Future research will focus on combining machine learning methods to build a more intelligent reputation evaluation model. For example, reinforcement learning can be used to model the process of calculating the reputation value as a dynamic decision-making problem, and the reputation evaluation rules can be dynamically adjusted through feedback, thereby improving the calculation accuracy of the reputation model and its adaptability in complex scenarios. In malicious node identification, the node interaction relationship in the consortium chain can be modelled as a graph structure, and the node feature information can be mined using graph neural networks to improve the ability to identify malicious nodes.