DC-PBFT: A Censorship-Resistant PBFT Consensus Algorithm Based on Power Balancing

Abstract

The classic design of the Practical Byzantine Fault Tolerance (PBFT) protocol relies on a centralized primary node, which not only creates a performance bottleneck but also introduces severe data censorship risks, threatening the data integrity and security of Edge Computing networks. To address this challenge, this paper proposes DC-PBFT (Decoupled PBFT), a censorship-resistant consensus protocol for Edge-Internet of Things (Edge-IoT) environments. The core innovation of DC-PBFT lies in the decoupling of the Proposer and Primary roles, supplemented by Verifiable Random Function (VRF)-based dynamic role rotation, which fundamentally eliminates the arbitrary power of a single node. Building on this, the protocol introduces a parallel group consensus mechanism: an elected Consensus Committee (CC) composed of Active Edge Nodes leads the consensus, while an independent Replica Network (RN) performs parallel validation. When a disagreement arises, the protocol triggers a global disagreement arbitration process involving all nodes to guarantee final consistency and attribute fault. To ensure long-term incentive compatibility, we also designed a hybrid election mechanism combining Proof-of-Stake and dynamic reputation, along with corresponding economic incentives and a tiered penalty system. Theoretical analysis proves that DC-PBFT satisfies Consistency and Liveness, and achieves strong censorship resistance guarantees. Simulation results demonstrate that DC-PBFT’s scalability significantly outperforms PBFT and RepChain; its reputation mechanism effectively improves long-term performance under sustained Byzantine attacks; and, compared to asynchronous censorship-resistant protocols like HoneyBadgerBFT, DC-PBFT achieves censorship resistance with over 45% lower transaction confirmation latency.

1. Introduction

With the proliferation of Internet of Things (IoT) devices, deploying blockchain in resource-constrained edge networks has attracted significant attention [1,2,3]. However, traditional Practical Byzantine Fault Tolerance (PBFT) [4], with its $O\left(N^2\right)$ communication complexity, struggles to meet the high concurrency demands of large-scale Edge Server clusters. Furthermore, existing lightweight consensus solutions often overlook the issue of data loss caused by the malfeasance of the Edge Gateway acting as the Primary node.

The core architecture of PBFT relies on a centralized primary node to sort and pack transactions into blocks and initiate the consensus process. This design concentrates immense power in a single entity, leading to two severe risks. First, the primary node constitutes a single point of performance bottleneck; if it crashes or is attacked, the entire network will stall until it recovers through a time-consuming view change process. Second, a more insidious threat is that a malicious or profit-driven primary can engage in transaction censorship by selectively ignoring or delaying requests from specific users, thereby undermining the system’s data integrity and service reliability, as illustrated in Figure 1. In mission-critical IoT scenarios with extremely high demands for data integrity, such as Industrial Internet of Things (IIoT) and Supply Chain Monitoring [5,6], this censorship risk becomes particularly prominent. Acting as a centralized bottleneck, a malicious Primary node can launch Selective Forwarding Attacks [7,8]. For instance, it may deliberately discard or delay critical alarm messages from specific sensors to hide anomalies in the production system, thereby eroding the security foundation of the entire monitoring network.

To address these challenges, it is urgent to build a novel BFT consensus mechanism that is not only decentralized and robust but also capable of adapting to the high concurrency and resource-constrained characteristics of Edge Computing environments. Although existing research has attempted to mitigate this problem through methods like random primary election, most have failed to fundamentally strip the primary of its ultimate control over block content. Our work is directly motivated by this gap. We aim to fundamentally dismantle the excessive centralization of power in PBFT, especially to deprive the primary of its ability to unilaterally censor transactions.

To this end, we propose a novel consensus protocol named DC-PBFT (Decoupled PBFT), specifically tailored for Edge-IoT architectures. The protocol introduces a system of checks and balances by decoupling core powers, perfectly matching the heterogeneous network structure composed of high-performance Edge Servers and lightweight IoT devices.

The main contributions of this paper can be summarized in the following four points:

• Proposed and implemented a Proposer-Primary decoupling framework for power balancing, limiting single-node power and enhancing censorship resistance.
• Designed a hybrid election mechanism combining stake and dynamic reputation, using weighted random sampling to improve fairness and resist Sybil attacks.
• Constructed an economic and reputation incentive model that aligns node interests with network security through rewards and penalties.
• Validated the protocol through rigorous theoretical analysis and simulation experiments. The analysis results show that DC-PBFT effectively enhances censorship resistance and security while maintaining performance overhead within an acceptable range, demonstrating good overall performance.

The structure of the rest of the paper is organized as follows: Section 2 reviews related work and background knowledge; Section 3 elaborates on the system model of DC-PBFT; Section 4 presents the core protocol design, including the lifecycle, election mechanism, role rotation, and consensus flow; Section 5 provides a theoretical analysis and proof of the protocol’s security; Section 6 will showcase the performance evaluation and experimental results; Section 7 concludes the paper and discusses future research directions.

2. Related Work and Background

2.1. PBFT Consensus Algorithm

Byzantine Fault Tolerance (BFT) [9] is a fundamental problem in the field of distributed systems, aiming to ensure that a system can reach consensus even when some nodes may exhibit arbitrary malicious behavior (i.e., Byzantine failures). The Practical Byzantine Fault Tolerance (PBFT) [4] protocol proposed by Castro and Liskov is a landmark work in this field, as it was the first to reduce the complexity of BFT algorithms from exponential to polynomial, making their application in practical systems feasible.

PBFT employs a Primary-driven three-phase protocol—pre-prepare, prepare, commit—to achieve consensus, as illustrated in Figure 2. Its advantage lies in providing deterministic instant finality and ensuring security as long as the number of faulty nodes does not exceed one-third of the total. However, the centralized nature of its architecture also introduces inherent flaws: the primary node not only becomes a performance bottleneck but also holds absolute power in ordering and packaging transactions. This creates opportunities for a malicious primary node to engage in transaction censorship, which is concealed and difficult to effectively constrain within the protocol itself.

2.2. Improvements to PBFT

To mitigate the inherent centralization risks and performance bottlenecks of PBFT, both academic and industrial communities have explored various improvement pathways. One category of early solutions retains the role of the primary node but seeks to decentralize authority through frequent rotation or randomized selection. For instance, Tendermint [10] employs a deterministic round-robin succession mechanism for selecting the block proposer. Further research [11] has introduced the use of Verifiable Random Functions (VRF) [12] for primary node election, enhancing the unpredictability and fairness of the selection process. However, such approaches do not fundamentally resolve the issue: within any given view or term, the elected primary node still retains unconstrained power over block proposal, leaving the risk of censorship unaddressed.

Another, more radical category of solutions completely abandons the concept of a primary node, allowing all replica nodes to participate in consensus on an equal footing, i.e., “leaderless” protocols. For example, HoneyBadgerBFT [13] utilizes an Asynchronous Common Subset (ACS) protocol [14], enabling each node to independently propose transactions, thereby achieving strong censorship resistance. The trade-off, however, is a significant increase in communication overhead and higher consensus latency, which limits its applicability in high-performance scenarios. Furthermore, recent studies have explored tailoring PBFT for IoT environments. For instance, Dong et al. [15] proposed IPBFT, which utilizes a voting sort clustering mechanism to reduce communication overhead and introduces group signatures to enhance privacy protection.

Significant efforts have focused on optimizing PBFT’s communication complexity, which is typically $O\left(N^2\right)$. Threshold signature [16] techniques allow multiple signatures from replicas to be aggregated into a single, constant-size signature, reducing communication overhead in phases like commit and lowering complexity closer to $O\left(N\right)$. Protocols like SBFT [17] and HotStuff [18] leverage this approach. HotStuff further introduces pipelining techniques, allowing consensus phases for different blocks to overlap, significantly boosting throughput, although it places stringent requirements on primary node stability and network conditions. Zyzzyva [19] introduced optimistic execution paths, assuming favorable network conditions and primary node honesty to reduce communication, but require complex fallback mechanisms when assumptions fail. DBFT [20] attempts to improve scalability by segregating node roles, though this might lead to centralization concerns.

Decoupling the responsibilities of transaction dissemination/ordering from the core consensus mechanism has emerged as a promising direction for high performance. Narwhal and Tusk [21] is an example, using a DAG-based mempool for reliable transaction broadcast and a separate consensus protocol for ordering batches, achieving very high throughput. While these works share the concept of role separation, their focus is primarily performance optimization, differing from our goal of enhancing censorship resistance through explicit power balancing between distinct proposer and primary roles.

Furthermore, integrating reputation models [22] into BFT consensus to improve leader selection reliability and overall security has become a popular direction. RepChain [23] calculates reputation based on voting behavior within shards to select leaders. PrestigeBFT [24] evaluates server reputation based on past behavior to select more trustworthy primary nodes. Others like RSHS [25], BtRal [26], RVC [27], CRPBFT [28] and TRBFT [29] utilize diverse metrics (service quality, consensus participation, edge computing metrics) and strategies (node evaluation, random selection, optimized communication structures) to leverage reputation.

While these improvements address various limitations of PBFT, none fully tackle the fundamental issue of unilateral censorship power held by the primary node within a given consensus round through a dedicated power-balancing mechanism like the one proposed in DC-PBFT.

2.3. Comparison of Role Decoupling Mechanisms

To clearly articulate the novelty of DC-PBFT, it is essential to distinguish its decoupling mechanism from existing works. While several prominent BFT protocols have adopted role separation, their fundamental design objectives and security guarantees differ significantly, as summarized below.

Protocols such as HotStuff and SBFT introduce role separation primarily to optimize communication complexity and computational overhead. HotStuff utilizes a star topology where the leader acts as a central collector for threshold signatures, reducing message complexity to $O\left(N\right)$. SBFT decouples the execution layer from the consensus layer. In standard PBFT, all replicas must both order and execute every transaction; SBFT, however, designates a small group of consensus replicas strictly to order transactions, while a separate set of execution nodes handles the computationally heavy smart contract execution. Despite these optimizations, the core power in both HotStuff and SBFT remains strictly centralized. The designated leader still retains the unilateral, dictatorial authority to select transactions, sequence them, and initiate consensus. If a leader becomes malicious, it can execute selective censorship attacks by deliberately ignoring specific transactions. Because this decoupling only offloads redundant computation or communication, rather than restricting the leader’s sequencing power, the protocol offers no native resistance against censorship.

Protocols like HoneyBadgerBFT achieve strong censorship resistance by entirely abandoning the concept of a primary node. It relies on an Asynchronous Common Subset (ACS) protocol and threshold encryption, allowing all nodes to propose transactions simultaneously. While this guarantees that no single node can censor transactions, the heavy reliance on complex cryptographic primitives and asynchronous broadcast protocols incurs an extremely high computational and latency overhead, making it impractical for resource-constrained Edge-IoT environments.

In contrast to the above approaches, the decoupling in DC-PBFT is engineered strictly for power balancing. DC-PBFT actively dismantles dictatorial control by dividing the traditional primary responsibilities into two distinct, cross-validating roles. Specifically, the Proposer is solely responsible for transaction aggregation and block assembly, whereas the Primary is exclusively tasked with validation and consensus initiation. A malicious Proposer cannot force consensus on a censored block without the Primary’s validation, and a malicious Primary cannot initiate consensus without a valid proposal. Coupled with VRF-based dynamic role rotation, this separation of powers ensures rapid recovery from censorship attempts, achieving robust censorship resistance without the paralyzing performance overhead of fully asynchronous protocols.

Table 1. Detailed comparison of role decoupling and censorship resistance mechanisms.

Consensus	Role Decoupling	Decoupling Objective	Censorship Resistance Mechanism	Global Arbitration	Comm. Complexity
PBFT [4]	No	N/A	None (Vulnerable to Leader)	No	$O\left(N^2\right)$
HotStuff [18]	Yes	Performance	Weak (Leader-dependent)	No	$O\left(N\right)$
SBFT [17]	Yes	Performance	Weak (Leader-dependent)	No	$O\left(N\right)$
HoneyBadgerBFT [13]	Leaderless	Security	Threshold Encryption & ACS	No	$O\left(N\right)$
DC-PBFT (Ours)	Yes	Power Balancing	Role Decoupling + VRF + Reputation	Yes	$O(N_c^2+N_r^2)$

provides a detailed theoretical comparison between DC-PBFT and highly relevant existing works across key dimensions.

3. System Model

This chapter aims to establish a clear and rigorous foundation for the subsequent protocol design and analysis. We will sequentially define the network communication environment upon which the protocol relies, the core components and concepts constituting the system, and the threat model we aim to defend against.

3.1. Network and Communication Model

We assume the protocol operates within a Partially Synchronous Network [30] environment. This model more closely reflects real-world distributed system environments and possesses the following specific characteristics:

• There exists an unknown Global Stabilization Time (GST) in the network. After GST, the network recovers synchrony, and any message sent by an honest node will be received by another honest node within a known but potentially unknown delay bound, $\Delta$.
• Before GST, the network can be completely asynchronous, where message delivery may suffer arbitrary delays or even loss.

This assumption implies that the network allows for temporary partitions or large-scale congestion but will not fail permanently. This provides a basis for designing consensus protocols that can tolerate network anomalies while still guaranteeing eventual liveness.

3.2. System Components and Core Definitions

This section aims to formally define the core entities comprising the DC-PBFT protocol and their key operational concepts, establishing a foundation for subsequent protocol design and analysis. The normal operation of the protocol relies on the coordinated work of nodes playing different roles and adherence to a series of core operational rules.

Node Roles The participating entities in the protocol are divided into the following categories based on their responsibilities.

• Replica: Serving as the fundamental units constituting the entire consensus network, all replica nodes store the complete ledger state and are responsible for executing confirmed transactions. They form the candidate pool for elections and may assume more specific consensus roles based on election results and protocol rules.
• Consensus Committee (CC): At the beginning of each epoch, an elite subset of size $N_c$ is selected from qualified replica nodes through a specific election mechanism. They act as data aggregation hubs for the region, responsible for ordering and packaging high-concurrency requests from IoT terminals.
• Replica Network (RN): Composed of all qualified replica nodes that meet the minimum staking requirement but were not elected into the Consensus Committee, its size is $N_r$. The Replica Network exists as an independent parallel validation layer, synchronously receiving block proposals issued by the Primary node along with the Consensus Committee, and independently executing the PBFT voting phases (Prepare, Commit) among its internal members to audit the consensus results of the Consensus Committee.
• Proposer: At a specific block height, a node dynamically assigned from within the Consensus Committee. Its core responsibility is to collect pending transactions from the transaction pool, validate their legitimacy, and package them into a new candidate block.
• Primary: At a specific block height, also a node dynamically assigned from within the Consensus Committee. It is responsible for receiving and validating the candidate block submitted by the Proposer, then constructing a PRE-PREPARE message and broadcasting it to all nodes participating in consensus across the network, thereby formally initiating the three-phase consensus voting for that block.
• Client: Refers to lightweight IoT terminals. Being resource-constrained, they do not store the ledger or participate in consensus voting. They are solely responsible for collecting data, performing digital signatures, and broadcasting transaction requests to nearby Edge Nodes.

The operation of the protocol follows several Core Operational Concepts.

• Epoch: The protocol operates in basic time units called epochs. Within a complete epoch, the membership composition of the Consensus Committee remains fixed, ensuring the stability of the consensus core during that period. The duration of an epoch can be adjusted based on network status or governance parameters.
• View: Inherited from the classic PBFT concept, a view represents one or more rounds of consensus attempts led by a specific Primary node. The View Change mechanism is triggered when the network suspects the current Primary has failed or is malicious, serving as an important mechanism to guarantee protocol liveness.
• Stake: Refers to the economic capital voluntarily locked and staked by replica nodes to gain eligibility for election. The stake amount is not only a participation threshold but also an important measure of a node’s commitment to network security, playing a role in election and penalty mechanisms.
• Reputation Score: As a quantitative measure of a node’s long-term reliability, the reputation score is dynamically assessed based on the node’s historical behavioral performance during the consensus process. It is a key factor influencing the probability of being elected to the committee and is updated by the subsequently defined reward and penalty incentive mechanism, aiming to guide nodes toward behaviors consistent with the overall interests of the network.

3.3. Threat Model

We assume the system faces a Byzantine adversary and adopt the Byzantine Fault Model. Assume that at any given moment, the total number of nodes participating in consensus is $N=N_c+N_r$, among which there are at most f Byzantine nodes, and the remaining $N-f$ are honest nodes. To ensure the safety of the protocol’s final arbitration, the entire network must satisfy the classic BFT assumption, namely $N\ge 3f+1$. Concurrently, the normal operation of the protocol, especially during the parallel consensus phase, relies on the election mechanism being able to ensure that the distribution of Byzantine nodes within the Consensus Committee and the Replica Network does not violate the $N\ge 3f+1$ condition within their respective groups.

The adversary is subject to the following limitations: The adversary cannot break the cryptographic primitives relied upon by the protocol, for example, they cannot forge the digital signatures of honest nodes or break hash functions. The total number of Byzantine nodes controlled by the adversary at any moment cannot exceed f. Furthermore, the adversary cannot disrupt network communication indefinitely; that is, the network will eventually enter a synchronous state according to the partial synchrony assumption.

4. Design of DC-PBFT Consensus Protocol

4.1. Protocol Lifecycle Overview

The DC-PBFT protocol aims to construct an efficient and censorship-resistant Byzantine Fault Tolerant consensus mechanism through the introduction of checks and balances and economic incentives. The protocol operates following a structured lifecycle, which runs in recurring cycles known as epochs. As shown in Figure 3, its complete lifecycle can be divided into the following three core phases:

• Initialization and Committee Election Phase: At the beginning of each new epoch, the system elects a new consensus committee from all network nodes via a hybrid election mechanism that combines Proof of Stake (PoS) [31] and dynamic reputation. This phase establishes the legitimate validator set for the current epoch, laying the security foundation for its operation.
• Consensus Operation and Block Production Phase: Within an epoch, committee members take turns serving as the Block Proposer and the Primary Node according to a deterministic, random sequence. The production and finalization of new blocks are accomplished through an improved three-phase consensus process. The core innovation of this phase lies in the cross-verification mechanism between the Proposer and the Primary Node, which fundamentally prevents the possibility of single-point censorship or block forgery, constituting the key to achieving effective checks and balances.
• Incentive, Evaluation, and Epoch Transition Phase: The entire consensus process is driven by a closed-loop economic and reputation incentive mechanism. This system continuously records node behaviors and performs settlements upon block finalization or at the end of an epoch, thereby rewarding honest behavior and penalizing malicious nodes. Once an epoch reaches its predefined block count or time threshold, the current lifecycle terminates, and the system automatically triggers the committee election for the next epoch, initiating a new lifecycle cycle.

4.2. Committee Election Mechanism

The committee election is the foundational step of each new epoch, with the core objective of selecting a consensus committee of appropriate size, high robustness, and decentralization from the entire network of nodes. This section will elaborate on the election process and core mechanisms designed for this purpose in the DC-PBFT protocol.

4.2.1. Candidacy and Committee Size

The primary stage of the election is candidacy screening. Any replica wishing to participate in consensus must stake an amount of tokens exceeding a predefined system threshold $STAC{K}_{MIN}$ to become a candidate. Subsequently, the system dynamically calculates and determines the committee size, N, for the current epoch based on the total number of qualified candidates, $N_{cand}$.

4.2.2. Probabilistic Election and Weight Model

To ensure the fairness and security of the committee election, this protocol avoids deterministic schemes based on weight ranking. While simple, such schemes suffer from inherent risks of centralization ossification and high predictability, making the network vulnerable to targeted attacks.

In response, DC-PBFT employs a probabilistic election mechanism based on Weighted Random Sampling. The core of this mechanism is that a node’s comprehensive election weight, $W_i$, does not directly determine its selection but rather serves as its probability of being chosen. The weight is calculated using a weighted linear combination model designed to balance economic investment and historical behavior, defined as:

$$W_i=\alpha ·{\widehat{S}}_i+(1-\alpha )·{\widehat{R}}_i$$

(1)

where the staking score ${\widehat{S}}_i$ and reputation score ${\widehat{R}}_i$ are calculated as follows: First, let $S_i$ and $R_i$ represent the original stake amount and reputation score of node i, respectively. To mitigate the linear advantage of whale nodes and reflect the diminishing marginal effect of capital, the protocol applies a logarithmic transformation to the original stake amount $S_i$:

$$S_i^{\prime }=\ln (1+S_i)$$

(2)

Next, the transformed stake value $S_i^{\prime }$ and the original reputation score $R_i$ are scaled to the $[0,1]$ range using Min-Max Nordmalization across the set of all current candidates, C, to obtain the final scores:

$${\widehat{S}}_i={\displaystyle \frac{S_i^{\prime }-{\min }_{j\in C}\left(S_j^{\prime }\right)}{{\max }_{j\in C}\left(S_j^{\prime }\right)-{\min }_{j\in C}\left(S_j^{\prime }\right)}}$$

(3)

$${\widehat{R}}_i={\displaystyle \frac{R_i-{\min }_{j\in C}\left(R_j\right)}{{\max }_{j\in C}\left(R_j\right)-{\min }_{j\in C}\left(R_j\right)}}$$

(4)

The parameter $\alpha \in [0,1]$ is a system variable, adjustable via governance, used to regulate the relative importance of staked capital versus historical reputation in the election process.

4.2.3. Deterministic Pseudo-Randomness Implementation

To ensure that the weighted random sampling process yields a deterministic and unique result across all honest nodes, the protocol introduces a Deterministic Pseudo-randomness scheme. The core of this scheme is that all nodes must synchronously execute a fully deterministic sampling algorithm based on a public and unpredictable random seed. The protocol stipulates that the hash of the last finalized block from the previous epoch serves as the public random seed for the current election, denoted as $See{d}_{epoch}$. This seed is an ideal source of entropy due to its properties of being publicly visible, computationally determined, difficult to predict, and resistant to manipulation.

At the start of the election, all nodes use this public seed as the initial input and iteratively perform N rounds of sampling. In the k-th round $(1\le k\le N)$, the deterministic random number for that round, $r_k$, is derived through the following hash operation:

$$r_k=\mathrm{Hash}(See{d}_{epoch}\left|\right|k)$$

(5)

where $\left|\right|$ denotes byte string concatenation. This derived random number, $r_k$, is then used for the sampling decision. Subsequently, the protocol employs the Weighted Roulette Wheel algorithm to precisely select one committee member. Specifically, the system first calculates the total weight of all nodes in the current candidate pool $C_k$, denoted as $W_{\mathrm{total}}={\sum }_{j\in C_k}{W}_j$. The selected member, $m_k$, is the one that satisfies the following condition:

$$\sum _{j=1}^{m_k-1}{W}_j\le r_k·W_{total}<\sum _{j=1}^{m_k}{W}_j$$

(6)

Intuitively, this formula can be understood as arranging the weights of all candidates sequentially on a line and then using the random number $r_k$ to select a point on that line. The candidate whose weight interval contains this point is the one selected for the round. The selected member, $m_k$, is immediately removed from the candidate pool and does not participate in subsequent rounds of the election. Because the inputs ($See{d}_{epoch}$, candidate list) and the computational logic (hash function, roulette wheel algorithm) are identical for all nodes, this mechanism guarantees that all honest nodes will arrive at the exact same committee list. It elegantly integrates the fairness of probabilistic election (stemming from the unpredictability of the seed) with the consistency required by distributed systems (stemming from the deterministic nature of the algorithm). Furthermore, the non-deterministic outcome of the election significantly enhances the network’s resilience against long-term targeted attacks.

4.3. Role Rotation Mechanism

Within a given epoch, to eliminate the inherent high predictability and security risks of simple round-robin mechanisms, the protocol adopts a dynamic role assignment mechanism based on a Verifiable Random Function (VRF) [12]. This mechanism ensures that the role assignment for each round is unpredictable, resistant to manipulation, and publicly verifiable, serving as a critical component for guaranteeing the network’s decentralization and resilience against attacks.

Specifically, for any given block height h, the protocol uses the hash of the preceding block, $B_{h-1}$, as a network-wide uniform input seed, denoted as $see{d}_h=\mathrm{Hash}\left(B_{h-1}\right)$, Each member i of the current consensus committee uses its own VRF private key, $s{k}_i$, to compute on this seed, generating a random number output $y_i$ and its corresponding validity proof ${\pi }_i$:

$$(y_i,{\pi }_i)={\mathrm{VRF}}_{s{k}_i}\left(see{d}_h\right)$$

(7)

Subsequently, all members broadcast their computation results $(y_i,{\pi }_i)$ to the network. After collecting and verifying the VRF outputs from all members, the system follows a public and deterministic rule to assign roles: the node that produced the lowest random number output, $y_{min}$, is assigned as the Proposer for the current round, while the node that produced the second-lowest random number output is assigned as the Primary. Since no one can predict the hash of block $B_{h-1}$ before it is finalized, this mechanism significantly compresses the attacker’s preparation window, effectively defending against targeted attacks on future key roles and thereby substantially enhancing the protocol’s robustness.

4.4. Consensus Flow: Parallel Group Consensus Protocol

The consensus flow of this protocol is designed to significantly enhance consensus efficiency while ensuring security through an innovative parallel group design. The core idea is to partition all consensus nodes in the network into two independent consensus domains: an elite “Consensus Committee” and a broader “Replica Network.” By reducing the number of nodes participating in the BFT consensus within each domain, the protocol lowers the communication complexity from the traditional $O\left(N^2\right)$ of PBFT to two parallel sub-processes with complexities of $O\left(N_c^2\right)$ and $O\left(N_r^2\right)$, respectively. This approach substantially improves system performance and scalability while maintaining decentralized supervision. An overview of the entire consensus protocol’s message flow is illustrated in Figure 4.

4.4.1. Consensus Process

The initial stage of consensus is unified. Transaction requests from clients are sent to the Consensus Committee (CC). The Proposer node within the committee is responsible for collecting transactions, validating their legitimacy, and packaging them into a candidate block, $B_h$. Subsequently, the Proposer signs the block hash with its private key to construct a PROPOSAL message, which is then sent to the Primary node, also a member of the committee. The message format is as follows:

$$\langle \mathrm{PROPOSAL},h,\mathrm{digest}\left(B_h\right),{\sigma }_{prop}\rangle$$

(8)

Upon receiving this message, the Primary node must first perform rigorous validation: (1) verify the validity and legitimacy of the Proposer’s signature, ${\sigma }_{prop}$; (2) check if the Proposer is authorized to propose a block at the current height, h; and (3) obtain the full block $B_h$ from the Proposer or other nodes and independently validate all transactions within it. Only after all these verifications pass will the Primary proceed to the next step.

Once validation is successful, the Primary will broadcast a PRE-PREPARE message to all nodes in the network (including all CC and RN members) to initiate the global consensus. This message encapsulates the original block proposal as evidence, ensuring that all nodes begin the consensus process from an identical initial state:

$$\langle \mathrm{PRE}-\mathrm{PREPARE},v,h,B_h,{\sigma }_{prop}\rangle$$

(9)

Upon receiving the PRE-PREPARE message, the Consensus Committee (CC) and the Replica Network (RN) enter a phase of isolated, parallel consensus. The internal processes of both domains are identical and adhere to standard PBFT voting logic. Taking the Consensus Committee (CC) as an example, its internal process is as follows: each CC member, after receiving the PRE-PREPARE message, first performs cross-validation to confirm that the message is from the legitimate Primary and encapsulates a valid signature from the Proposer. After successful validation, the member broadcasts a PREPARE message exclusively to other CC members:

$$\langle \mathrm{PREPARE},v,h,\mathrm{digest}\left(B_h\right)\rangle$$

(10)

When a CC member has collected $2f_c+1$ valid PREPARE messages from within the CC, it will then broadcast a COMMIT message to other CC members:

$$\langle \mathrm{COMMIT},v,h,\mathrm{digest}\left(B_h\right)\rangle$$

(11)

The Replica Network (RN) conducts its voting process independently among its $N_r$ members in the exact same manner.

After the internal consensus process within each domain concludes (whether in success or failure), all participating nodes send their respective domain’s final consensus result back to the Proposer of the current round. The Proposer then makes a final decision based on the results from both domains according to the following rules:

• Unanimous Success: If both the Consensus Committee (CC) and the Replica Network (RN) successfully collect a sufficient number of COMMIT signatures to reach an intra-group consensus, the block $B_h$ is finalized. The Proposer will assemble and broadcast the final block certificate, and the consensus process concludes normally.
• Unanimous Failure: If both domains fail to reach a consensus due to a timeout or an insufficient number of votes, the block $B_h$ is discarded. The consensus fails, and the network proceeds to the consensus process for the next block height.
• Disagreement: If one domain reaches a successful consensus while the other fails, this is considered a critical network anomaly, indicating potential malicious behavior or a large-scale network failure. The system will automatically pause the normal process and trigger the disagreement arbitration mechanism.

4.4.2. Disagreement Arbitration

When the result of the consensus process is a “disagreement”—that is, one consensus domain successfully confirms the block while the other (the RN) fails—the system treats this as a critical security threat or network failure. Upon aggregating this conflicting result, the Proposer node immediately broadcasts a CHALLENGE message to the entire network, triggering a suspension of the normal process and initiating the high-cost Arbitration Consensus phase.

This arbitration process serves as the protocol’s ultimate security defense. All nodes (including all members of both the CC and the RN) will jointly conduct a new, complete, and unified PBFT consensus on the disputed block $B_h$. The outcome of this round is considered the incontrovertible “gold standard” and is used to perform precise fault attribution for the two consensus domains from the preceding parallel phase.

If the Arbitration Consensus “succeeds” (i.e., the entire node population ultimately accepts block $B_h$), this outcome proves that the block $B_h$ itself is legitimate and valid. Consequently, the consensus domain that “failed” during the parallel phase (the “failing group”) is determined to be the erring party. The system will not penalize all members of the “failing group”; rather, it will precisely penalize all nodes within that group that did not cast a COMMIT vote. This is because the arbitration proved the block was valid, and these nodes failed to correctly affirm it, thereby damaging network liveness.

Conversely, if the Arbitration Consensus “fails” (i.e., the entire node population ultimately rejects block $B_h$), this outcome proves that the block $B_h$ has critical flaws (e.g., contains invalid transactions). Consequently, the consensus domain that “succeeded” during the parallel phase (the “succeeding group”) is determined to be the malicious party, as its actions constituted a direct threat to network security. The system will precisely penalize all nodes within that “succeeding group” that cast a COMMIT vote, as they attempted to commit a block that was proven to be harmful.

Through this high-cost arbitration and precise attribution mechanism, the protocol ensures that during the normal parallel consensus phase, members of both consensus domains have a powerful incentive to validate and vote honestly. The specific punitive measures for the two aforementioned classes of penalized nodes, such as the detailed rules for economic slashing and reputation score adjustments, will be elaborated in Section 4.5, “Incentive and Penalty Mechanisms”.

Although the disagreement arbitration mechanism serves as the ultimate defense for system consistency, its high communication complexity dictates that it is a low-probability fallback mechanism. During a normal consensus period, the theoretical frequency of triggering this mechanism is extremely low. Since the consensus committee is generated through VRF-based random sampling from the entire network, under the assumption that the global malicious node ratio $f/N\le 1/3$, the distribution of malicious nodes within the committee follows a hypergeometric distribution. Natural disagreements are triggered only under extreme sampling deviations that lead to contradictory conclusions between the consensus committee and the replica nodes. Furthermore, any malicious primary node attempting to intentionally trigger arbitration by equivocating proposals will be accurately held accountable post-arbitration, facing the devastating penalty of complete stake slashing and reputation resetting. This game-theoretic deterrence prevents malicious nodes from abusing the arbitration mechanism.

To ensure that the independent voting of the RN does not become a performance bottleneck, it is crucial that disagreements—and the subsequent high-cost global arbitrations—remain rare under normal conditions. Theoretically, the expected frequency of disagreements is heavily dependent on the global Byzantine node ratio ($f/N$) and the committee ratio ($p=N_c/N$). Because the Consensus Committee is generated through VRF-based random sampling, the number of malicious nodes within the committee essentially follows a hypergeometric distribution.

Under normal network conditions (e.g., $f/N\le 10\%$), the probability of a sampling deviation severe enough to cause a divergent consensus outcome between the CC and RN is mathematically negligible. Furthermore, our empirical analysis in Section 6.1 confirms that expanding the total network size (N) and appropriately increasing the committee ratio (p) effectively flattens the variance of this distribution. This parametric adjustment significantly suppresses the disagreement rate even under elevated attack intensities. Therefore, by properly configuring N and p, the protocol ensures that the RN functions efficiently as a parallel auditor without triggering frequent arbitration bottlenecks.

4.5. Incentive and Penalty Mechanisms

A robust consensus protocol must not only be algorithmically secure but also incentive-compatible from a game-theoretic perspective. Incentive compatibility is a core concept in the field of mechanism design, referring to an institutional arrangement where all rational participants find that honestly adhering to the protocol’s rules is the optimal strategy to maximize their own self-interest [32,33]. The core objective of the economic and reputation model detailed in this section is precisely to achieve this incentive compatibility. This mechanism ensures that the individual interests of all participating nodes—whether in the Consensus Committee (CC) or the Replica Network (RN)—are aligned with the overall security and liveness of the network through a set of quantitative rules for rewards and penalties. To this end, this chapter will sequentially introduce the reward mechanism for honest behavior, the penalty mechanism for malicious and negligent behavior, and finally, the dynamic update model that links these outcomes to node reputation and stake, thereby constructing a complete game-theoretic loop.

To achieve this game-theoretic loop, the protocol’s reputation system is designed to follow a lightweight, event-driven model. First, a node’s raw reputation score, $R_i$, is strictly bounded within the $[0,1]$ interval, where $R_{max}=1.0$ represents a perfectly trustworthy node, and $R_{min}=0.0$ represents a known malicious node. Second, when a new node joins the network, its reputation score is set to a neutral median value of $R_{initial}=0.5$; the node must then prove its reliability through subsequent honest actions. The subsequent incentive and penalty mechanisms will use a unified mathematical model to dynamically perform weighted updates on this reputation score, thereby achieving asymmetric punitive force.

4.5.1. Reward Mechanism

To resolve the “reward dilution” problem that occurs when the Replica Network (RN) scales, this protocol adopts a Dynamic Relative Share Model. This model does not preset a reward percentage for roles but rather allocates a relative reward share commensurate with their workload and risk, supplemented by a parallel reputation incentive.

In a “unanimous success” consensus round, the total reward pool, $R_{total}$ (composed of token issuance and transaction fees), is distributed according to total shares. We define a base share unit, $S_{base}$, and allocate shares to the different roles: $\alpha$ for the Proposer, $\beta$ for the Primary, and 1 for a regular voter. The total shares, $S_{total}$, for that round are calculated as follows:

$$S_{total}=\alpha +\beta +1\times (N_{voters}-2)$$

(12)

In this formula, $S_{total}$ represents the total number of shares for reward distribution; $\alpha$ and $\beta$ are the reward multipliers for the Proposer and Primary, respectively; and $N_{voters}$ is the total number of nodes (including CC and RN members) that participated in the “unanimous success” vote. Subsequently, the value of each share, $S_{value}$, is determined:

$$S_{value}={\displaystyle \frac{R_{total}}{S_{total}}}$$

(13)

Here, $R_{total}$ is the total reward pool for the block. Finally, the economic rewards for each role are determined:

$$\left\{\begin{array}{cc}\hfill R_{\mathrm{proposer}}& =\alpha ·S_{\mathrm{value}}\hfill \\ \hfill R_{\mathrm{primary}}& =\beta ·S_{\mathrm{value}}\hfill \\ \hfill R_{\mathrm{voter}}& =1·S_{\mathrm{value}}\hfill \end{array}\right.$$

(14)

where $R_{proposer}$, $R_{primary}$, and $R_{voter}$ represent the final economic rewards obtained by the Proposer, Primary, and regular voters, respectively. In the design and analysis of this protocol, we set the parameters $\alpha =10$ and $\beta =2$. This model ensures that as the RN size (and thus $N_{voters}$) grows, the rewards for all roles are diluted proportionally. However, the relative incentive for the Proposer and Primary compared to a regular voter remains constant, thus solving the scalability issue while maintaining incentive compatibility.

Second, for reputation incentives, the protocol applies a weighted update model to dynamically adjust the node’s reputation score, $R_i$. This model ensures the score always remains within the bounded [0, 1] interval. Its general update formula is:

$$R_{i,new}=(1-w)·R_{i,old}+w·T$$

(15)

In this formula, $R_{i,new}$ and $R_{i,old}$ represent the node’s new and old reputation scores, respectively; T is the target value of the event; and w is the weight of the event ($w\in [0,1]$). For a node that votes honestly in a “unanimous success” round, the system will update its reputation score using a target value $T=1.0$ (pulling it towards “perfect reputation”) and a weight $w=w_{reward}$. Here, $w_{reward}$ is a small constant (e.g., $w_{reward}=0.01$), representing the contribution weight of a single honest action to the total reputation. This mechanism incentivizes nodes to maintain continuous honesty, allowing their reputation score $R_i$ to gradually climb and approach 1.0.

4.5.2. Penalty Mechanism

The penalty mechanism aims to impose negative consequences on nodes that impair network security or liveness, thereby deterring malicious behavior and maintaining the protocol’s incentive compatibility. This protocol classifies violations into three levels based on their nature and severity: minor violations, moderate violations, and severe violations. The specific violating behaviors, corresponding reputation penalty weights, and economic penalty measures are detailed in

Table 2. Penalty details for violating behaviors.

Violation Level	Reputation Target (T)	Reputation Weight (w)	Economic Penalty	Violating Behavior
Minor	0	$0.05$	None	Cumulative timeouts exceeding threshold $\tau$ (e.g., Proposer/Primary/Node timeouts within $T_{window}$) Node ignores Challenge/Arbitration
Moderate	0	$0.3$	Minor	Incorrect Rejection (Failed group, no COMMIT, Arb. Success)
Severe	0	$1.0$	Confiscation	Malicious Confirmation (Succeeded group, COMMIT, Arb. Failure) Double Signing/Equivocation Malicious Proposal (Invalid Tx) Malicious Coordination (Tampered Proposal) Malicious Aggregation (Hides Disagreement)

.

All penalties follow the weighted update model introduced in Section 4.5.1 for reputation adjustment, with the general formula:

$$R_{i,new}=(1-w_{penalty})·R_{i,old}+w_{penalty}·T$$

(16)

In this formula, $R_{i,new}$ and $R_{i,old}$ represent the node’s new and old reputation scores, respectively. For all penalty events, the target value T is set to 0.0, meaning all penalties aim to pull the node’s reputation score towards the minimum value. The severity of the penalty is implemented by adjusting the weight $w_{penalty}$ (where $w_{penalty}\in [0,1]$) and the degree of economic penalty.

Minor violations, i.e., liveness faults, primarily cover behaviors where a node fails to perform its duties on time, such as Proposer or Primary timeouts or node disconnections. These actions mainly affect network efficiency rather than security. For such violations, the reputation penalty weight $w_{penalty}$ is set to a small value, e.g., 0.05, and is not accompanied by economic penalties. To balance fairness and deterrent effect, the protocol introduces a cumulative evaluation mechanism based on a sliding window for these minor violations. The system monitors a node’s performance over the past $T_{window}$ blocks. A reputation penalty is triggered and applied only if the number of recorded timeouts exceeds a predefined fault-tolerance threshold $\tau$. This design effectively filters out false positives caused by transient network fluctuations or objective network delays, distinguishing them from intentional misbehavior.

Furthermore, although minor violations do not involve direct economic slashing, the resulting drop in the reputation score will directly reduce the node’s election weight $W_i$. This consequently lowers its probability of being selected for the Consensus Committee in future epochs. From a game-theoretic perspective, the opportunity cost of lost future block rewards and transaction fees caused by “lazy” or passive behavior far exceeds the marginal energy savings gained from staying offline. This opportunity cost essentially acts as a strict economic deterrent, ensuring the continuous liveness of rational nodes.

Moderate violations, i.e., non-conforming consensus, where a node fails to correctly identify a block ultimately proven legitimate by arbitration. For such behavior, the reputation penalty weight $w_{penalty}$ is set to a significantly higher value. Additionally, Minor Slashing is imposed, with the slashed amount $P_{minor}$ calculated as a fixed small percentage ${\rho }_{minor}$ of the node’s current stake $S_i$:

$$P_{minor}={\rho }_{minor}·S_i$$

(17)

In the analysis of this protocol, we set ${\rho }_{minor}=0.01$. This design is intended to effectively deter “malicious rejection” or “inaction” behaviors from Replica Network (RN) members.

Severe violations, i.e., malicious consensus, encompass all behaviors that explicitly compromise network security and consistency, such as maliciously confirming harmful blocks, double-signing, malicious proposals, or malicious result aggregation. For such actions, the protocol imposes the strictest penalties: the reputation penalty weight $w_{penalty}$ is set to the maximum value of 1.0, causing the node’s reputation score to drop directly to zero. Concurrently, Major Slashing is imposed, for instance, confiscating the node’s entire stake $S_i$. This devastating penalty aims to completely eliminate the economic incentive for nodes to engage in such malicious attacks.

5. Security Analysis

This chapter aims to perform formal analysis and proof of the key security properties of the DC-PBFT protocol under the system model and threat model defined in Section 3. We will sequentially provide detailed arguments for the protocol’s consistency, liveness, and its core design objective, censorship resistance.

5.1. Consistency

Consistency is the core safety property of a consensus protocol, ensuring that all honest nodes have a unified view of the ledger state, meaning the protocol does not produce “forks.” Specifically, within the DC-PBFT protocol, this implies that under the partial synchrony network model and the Byzantine fault model (where the entire network $N=N_c+N_r\ge 3f+1$), no two honest replica nodes will finally confirm two different blocks, B and $B^{\prime }$, at the same block height h.

The protocol guarantees this through its unique two-phase confirmation mechanism. A block can only be finally confirmed via one of two paths: first, during the parallel consensus phase, both the Consensus Committee and the Replica Network reach a consensus on the block; second, after a disagreement arises in the parallel phase, an arbitration consensus involving all nodes ultimately decides to accept the block.

It is impossible for two different blocks, B and $B^{\prime }$, to be finally confirmed at the same height h. Firstly, they cannot both be confirmed via the “unanimous success” path. If block B achieves unanimous success, it means both the Consensus Committee and the Replica Network reached a consensus on it. Assuming the Replica Network temporarily satisfies the Byzantine fault tolerance condition internally, then according to the consistency guarantee of the PBFT protocol itself, the honest nodes within the Replica Network cannot subsequently reach a consensus on another different block $B^{\prime }$. Therefore, $B^{\prime }$ cannot obtain confirmation from the Replica Network, failing to meet the “unanimous success” condition.

Secondly, two different blocks cannot both be confirmed via the “arbitration confirmation” path either. The arbitration consensus involves all N nodes and is a standard BFT process conducted under the premise that the entire network satisfies $N\ge 3f+1$. According to classic BFT theory, all honest nodes will inevitably reach a single, consistent decision regarding the arbitration outcome. Thus, arbitration cannot simultaneously confirm two different blocks.

Finally, it is also impossible for one block to be confirmed via “unanimous success” and another via “arbitration confirmation.” If block B is confirmed through “unanimous success,” this means there was no disagreement between the Consensus Committee and the Replica Network. According to the protocol rules, the arbitration consensus would not be triggered at all in this case. Consequently, block $B^{\prime }$ cannot be confirmed via the arbitration path.

In summary, the DC-PBFT protocol, by combining the efficient path of parallel consensus with the ultimate safety guarantee of arbitration consensus, ensures that under all circumstances, all honest nodes will only finally confirm a single, unique block state at the same block height, thereby satisfying the consistency requirement.

5.2. Liveness

Liveness guarantees that the protocol can continuously make progress, eventually confirming legitimate transactions submitted to the network. DC-PBFT ensures liveness through its view change mechanism and the partial synchrony network assumption.

Should the proposer or the primary node fail, for example by failing to perform duties before a timeout, the protocol will trigger the view change mechanism. By broadcasting VIEW-CHANGE messages, the failed primary will be replaced, ensuring the consensus process can be taken over and continued by a new, honest primary node, which will eventually be selected.

To prevent the system from entering an infinite loop of view changes, the protocol employs an exponential backoff strategy for timeout timers. Combined with the partial synchrony network model, which guarantees bounded message delay after the Global Stabilization Time, the timeout duration will eventually exceed the actual network delay. As long as an honest primary is eventually selected and the network enters a synchronous state, consensus, whether through the normal process or arbitration, will successfully complete, breaking any cycle and ensuring the protocol can continuously produce new blocks, even if they are empty blocks. Therefore, legitimately submitted transactions that are continuously broadcast will eventually be included by an honest proposer and confirmed, satisfying the liveness requirement.

Furthermore, DC-PBFT exhibits strong resilience against arbitration-based stalling attacks. A concern might be whether a specific subgroup of Byzantine nodes could intentionally and repeatedly force the network into the high-cost global arbitration state to degrade performance. This is prevented by the protocol’s definitive fault attribution and strict penalty mechanisms. If malicious nodes intentionally trigger a disagreement (e.g., a malicious Primary sending conflicting proposals to the Consensus Committee and Replica Network), the subsequent global arbitration will irrefutably determine the valid block. Nodes that voted against the arbitrated truth are subsequently identified as malicious and subjected to Major Slashing (complete confiscation of staked tokens and reputation reset). Because the economic cost of initiating such an attack is devastating, an attacker can trigger a stall at most once before losing all consensus privileges. Therefore, intentionally forcing arbitration constitutes an unsustainable “suicide attack”, guaranteeing the long-term liveness and operational efficiency of the network.

5.3. Censorship Resistance

Definition 1 (Eventual Censorship Resistance).

Assume the network has reached the Global Stabilization Time (GST) and the Consensus Committee (CC) satisfies the Byzantine assumption $N_c\ge 3f_c+1$. A consensus protocol provides Eventual Censorship Resistance if, for any valid transaction $tx$ that has been broadcast to the CC, the probability that $tx$ is not finalized within k consecutive consensus rounds, denoted as $P_{\mathrm{censor}}\left(k\right)$, is strictly bounded by an exponentially decreasing function:

$$P_{\mathrm{censor}}\left(k\right)\le {\left({\displaystyle \frac{f_c}{N_c}}\right)}^k<{\left({\displaystyle \frac{1}{3}}\right)}^k$$

(18)

As the number of rounds $k\to \infty$, $P_{\mathrm{censor}}\left(k\right)\to 0$. This guarantees that a persistent adversary cannot censor a transaction indefinitely with non-negligible probability.

Theorem 1. 

DC-PBFT satisfies Eventual Censorship Resistance as defined in Definition 1.

Proof. 

To censor a valid transaction $tx$, the adversary must prevent it from being included in a finalized block. We analyze the probability of this happening in a single consensus round $R_i$, assuming the network is post-GST.

Case 1: An honest node is selected as the Proposer. By protocol rules, an honest Proposer will include all valid transactions (including $tx$) available in its mempool into the candidate block $B_h$, and sign it. Due to the Proposer-Primary decoupling mechanism, the Primary node cannot unilaterally alter the content of $B_h$ (as it is protected by the Proposer’s digital signature ${\sigma }_{prop}$). If the Primary is honest, it broadcasts $B_h$, and since $N_c\ge 3f_c+1$, $B_h$ will be finalized by the CC. If the Primary is malicious and refuses to broadcast $B_h$, it triggers a View Change. The VRF-based rotation guarantees that a new Primary will eventually be selected. Since $B_h$ is already constructed and signed, the protocol rules dictate that the new Primary must process the pending valid proposal. Thus, if the Proposer is honest, $tx$ will eventually be finalized in round $R_i$ or its subsequent view changes.

Case 2: A malicious node is selected as the Proposer. In this scenario, the malicious Proposer can intentionally omit $tx$ from block $B_h$. Consequently, $tx$ cannot be finalized in round $R_i$.

Probability Analysis: The role of Proposer is determined dynamically via a VRF based on the unpredictable hash of the previous block. Assuming the VRF output is uniformly distributed, the probability that a specific node is selected as the Proposer is proportional to its presence in the CC. Since the CC contains at most $f_c$ malicious nodes out of $N_c$ total nodes, the probability $P_{\mathrm{malicious}\_\mathrm{proposer}}$ that a malicious node is elected as Proposer in any given round is exactly:

$$P_{\mathrm{malicious}\_\mathrm{proposer}}={\displaystyle \frac{f_c}{N_c}}$$

(19)

Given the BFT safety assumption $N_c\ge 3f_c+1$, we have:

$${\displaystyle \frac{f_c}{N_c}}\le {\displaystyle \frac{f_c}{3f_c+1}}<{\displaystyle \frac{1}{3}}$$

(20)

Because the VRF seed changes completely unpredictably from block to block (driven by $\mathrm{Hash}\left(B_{h-1}\right)$), the election events across different rounds are cryptographically independent. Therefore, the probability that $tx$ is censored for k consecutive rounds (i.e., malicious proposers are drawn k times in a row) is:

$$P_{\mathrm{censor}}\left(k\right)={\left(P_{\mathrm{malicious}\_\mathrm{proposer}}\right)}^k={\left({\displaystyle \frac{f_c}{N_c}}\right)}^k<{\left({\displaystyle \frac{1}{3}}\right)}^k$$

(21)

As $k\to \infty$, ${\lim }_{k\to \infty }{\left({\displaystyle \frac{1}{3}}\right)}^k=0$. This proves that the probability of an adversary successfully censoring a transaction indefinitely is negligible. □

Remark 1 (Impact of Reputation Mechanism).

While the mathematical bound above relies on the static assumption of $f_c$ malicious nodes, the dynamic reputation mechanism in DC-PBFT further tightens this bound in practice. If a malicious node happens to be selected as Proposer and engages in systematic censorship (e.g., consistently ignoring high-fee transactions), it will be identified during the Replica Network (RN) parallel auditing process or subsequent client complaints. The resulting severe penalty (reputation drop to 0, stake slashing) will immediately remove the node from the candidate pool for future epochs, effectively reducing $f_c$ over time and accelerating the decay rate of $P_{\mathrm{censor}}\left(k\right)$.

5.4. Security Against Adaptive Adversaries

To rigorously evaluate the robustness of the hybrid election mechanism, this section defines a formidable adversary model and provides formal proofs of the protocol’s security against randomness seed manipulation and long-term reputation exploitation.

Definition 2 (Adaptive Adversary).

An adaptive adversary $\mathcal{A}$ is assumed to be computationally bounded and capable of observing all public states, including blocks, VRF outputs, and reputation scores. $\mathcal{A}$ can dynamically corrupt up to f nodes at any moment but is strictly prohibited from breaking underlying cryptographic primitives, such as hash functions, digital signatures, and Verifiable Random Functions (VRFs).

Theorem 2 (Unpredictability and Bias-Resistance of the Election Seed).

An adaptive adversary $\mathcal{A}$ cannot bias the election probability of any node by manipulating the randomness seed $See{d}_{period}$.

Proof. 

The election seed is derived from the hash of the last finalized block of the preceding period: $See{d}_{period}=Hash\left(B_{last\_finalized}\right)$. To execute a grinding attack—testing multiple block payloads to generate a favorable hash—$\mathcal{A}$ must be able to unilaterally modify the finalized block. However, according to DC-PBFT consensus rules, a block is finalized only after accumulating at least $2f_c+1$ valid COMMIT signatures from the Consensus Committee. Even if $\mathcal{A}$ controls $f_c$ malicious nodes and serves as the Proposer, it cannot forge the signatures of the remaining $f_c+1$ honest nodes. Any alteration to the block payload invalidates the existing honest signatures, thereby preventing the block from reaching consensus. Consequently, $\mathcal{A}$ is compelled to accept the naturally generated, unpredictable hash as the VRF input, ensuring the election process is strictly bias-resistant. □

Theorem 3 (Resistance to Reputation Manipulation and Sleeper Attacks).

Under the asymmetric penalty model, the expected utility of a “sleeper attack”—maintaining honest behavior long-term to maximize reputation for a single severe malicious act—is strictly negative for any rational adaptive adversary $\mathcal{A}$.

Proof. 

Let $U_{attack}$ be the expected utility of a sleeper attack. We define $U_{attack}=G_{attack}-(L_{slash}+L_{future})$, where $G_{attack}$ represents the illicit gain from a single violation, $L_{slash}$ is the immediate economic penalty, and $L_{future}$ is the present value of lost future rewards.

According to the penalty mechanism defined in Section 4.5.2, a severe violation triggers Major Slashing: $L_{slash}=S_i$ (complete confiscation of the staked tokens) and an instantaneous reputation reset to zero ($w_{penalty}=1.0$). Consequently, the node’s future election probability drops precipitously, rendering $L_{future}\gg 0$. Conversely, reputation accumulation is intentionally designed as a slow, linear process ($w_{reward}\ll 1$), making the time cost to restore reputation to previous levels prohibitively high. Since the sum of the direct financial slashing and the severe opportunity cost of lost future block rewards ($L_{slash}+L_{future}$) is mathematically guaranteed to significantly outweigh any bounded single-block gain $G_{attack}$, we have $E\left[U_{attack}\right]<0$. Therefore, the optimal strategy for a rational adversary $\mathcal{A}$ is continuous honest behavior, satisfying the requirement for incentive compatibility. □

5.5. Game-Theoretic Analysis of Incentive Compatibility

To formally analyze the incentive compatibility of DC-PBFT, we model the decision-making process of a rational node i using an Expected Utility function. For any action a (honest or malicious), the node’s expected utility $U_i\left(a\right)$ over an infinite horizon is defined as:

$$U_i\left(a\right)=E\left[R_{imm}\left(a\right)\right]-C_{slash}\left(a\right)+\sum _{t=1}^{\infty }{\delta }^t·P_{elect}\left(R_i^{\left(t\right)}\left(a\right)\right)·R_{avg}$$

(22)

where $E\left[R_{imm}\left(a\right)\right]$ is the immediate block reward, $C_{slash}\left(a\right)$ is the economic penalty (slashing), $\delta \in (0,1)$ is the discount factor, $R_i^{\left(t\right)}\left(a\right)$ is the dynamic reputation score at future period t resulting from action a, and $P_{elect}$ is the probability of being elected to the consensus committee (which is directly proportional to reputation $R_i$). $R_{avg}$ is the average reward per period.

Based on this model, we analyze two primary attack vectors:

1. Strategic Reputation Manipulation (Sleeper Attack): An adaptive adversary may behave honestly for a long time to maximize its reputation $R_i\approx 1$, and then launch a severe attack (e.g., double signing) to gain a one-time illicit profit $G_{attack}$. However, according to our penalty mechanism, a severe violation results in total stake confiscation ($C_{slash}=S_i$) and an instantaneous reputation reset to zero ($R_i=0$). Consequently, the future election probability $P_{elect}\left(0\right)$ drops to zero. The expected utility of the attack is:

$$U_i\left(attack\right)=G_{attack}-S_i+0$$

(23)

Conversely, the utility of continuous honest behavior is $U_i\left(honest\right)=R_{voter}+{\displaystyle \frac{\delta }{1-\delta }}·P_{elect}\left(1\right)·R_{avg}$. Since the discounted future rewards of a high-reputation node infinitely accumulate and $S_i$ is significant, it strictly guarantees that $U_i\left(honest\right)>U_i\left(attack\right)$. The optimal strategy for a rational node is continuous honesty.

2. Collusion between CC and RN Members: To successfully manipulate consensus via collusion, adversaries must simultaneously control key positions in both the consensus committee and the replica network within the same period. Let $P_{collusion}$ be the probability of successfully achieving this distribution. As proven in Section 5.3, due to the VRF-based dynamic rotation and hypergeometric distribution, $P_{collusion}$ is mathematically negligible ($P_{collusion}\to 0$). The expected utility of a collusion attempt is:

$$E\left[U_{collusion}\right]=P_{collusion}·G_{collusion}-(1-P_{collusion})·(S_i+V_{future})$$

(24)

Given $P_{collusion}\approx 0$, the expected utility is heavily dominated by the slashing penalty and reputation destruction, rendering $E\left[U_{collusion}\right]<0$. Thus, forming a collusion cartel is irrational and economically self-destructive.

5.6. Parameter Sensitivity and Incentive Compatibility Bounds

To prove the stability of the system, this section conducts a sensitivity analysis on the core parameters based on the expected utility function. To ensure incentive compatibility, the reward multiplier $\alpha$ for the Proposer must be large enough to resist potential off-chain bribes $B_{censor}$. The theoretical condition for honesty is:

$$\alpha >{\displaystyle \frac{B_{censor}-P_{catch}·(V_{future}\left(1\right)+S_i)}{S_{value}}}$$

(25)

where $P_{catch}$ is the probability of being detected during arbitration. Given our high-probability arbitration mechanism, $P_{catch}\approx 1$. Setting $\alpha =10$ provides a massive safety margin, ensuring that honest block proposal is always the optimal strategy.

To prevent passive validation (saving computational cost $C_{compute}$), the parameters must satisfy:

$$C_{compute}<{\rho }_{minor}·S_i+w_{penalty}·R_{old}·{\displaystyle \frac{\partial V_{future}}{\partial R}}$$

(26)

Our analysis shows that setting ${\rho }_{minor}=0.01$ and $w_{penalty}=0.3$ effectively combines immediate economic loss with long-term reduction in election probability, eliminating the profit margin for passive validation.

6. Performance Analysis

This section presents the findings of performance testing experiments conducted on the DC-PBFT protocol. The experimental environment utilized the Ubuntu 20.04 operating system, an AMD 9600X CPU, and was equipped with 32 GB of RAM; the experimental code was implemented in C++. The simulation was configured with a partial synchrony network model, where the base inter-node latency was set to 50 ms and the bandwidth was limited to 100 Mbps. To comprehensively evaluate the protocol under various attack intensities, the number of Byzantine nodes, denoted as f, is controlled by the global Byzantine ratio ($f/N$). In experiments where the total network size N varies, f dynamically scales according to this ratio. In experiments with a fixed N, the exact number of Byzantine nodes f is explicitly specified. The workload was generated by simulated clients continuously submitting 256-byte transactions. We use the Ed25519 elliptic curve algorithm for digital signatures and SHA-256 as the hash function.

The simulation was configured within a fully connected network topology, operating under a partial synchrony model. To emulate realistic network fluctuations in Edge-IoT environments, we introduced network jitter: the inter-node latency follows a normal distribution with a mean of 50 ms and a standard deviation of 5 ms ($\mathcal{N}(50,5^2)$).

To ensure strict statistical significance, all quantitative results reported in this section represent the average of 20 independent simulation runs using different random seeds. The duration of each standard run was set to process a total of 1000 blocks. In the performance visualization figures, error bars are included to indicate the 95% confidence intervals, illustrating the statistical variability across these independent executions.

6.1. Disagreement Rate Analysis

In the DC-PBFT protocol, when the consensus results of the Consensus Committee (CC) and the Replica Network (RN) are inconsistent, a high-cost arbitration consensus is triggered. Therefore, the disagreement rate is a key internal metric for measuring the protocol’s stability and practical operational efficiency. In our experiments, we found that the disagreement rate is influenced by two main factors: the total number of nodes and the proportion of committee nodes. Figure 5 shows how these three factors—global Byzantine node ratio ($f/N$), consensus committee size ratio ($p=N_c/N$), and total number of nodes (N)—affect the disagreement rate.

The experimental results indicate that as the global Byzantine node ratio increases, the overall magnitude of the disagreement rate rises significantly, showing that attack intensity is the primary factor affecting stability. The DC-PBFT protocol consistently exhibits a unified trend across different network scales (N): the greater the total number of nodes, the lower the disagreement rate. At $f/N=30\%$ with $p=20\%$ and $N=50$, the disagreement rate is as high as nearly 70%, whereas in a larger network with $N=200$ under the same conditions, the disagreement rate drops to approximately 35%, a stability improvement of nearly 50%. Furthermore, the committee ratio (p) is also a critical tuning parameter. Under high attack intensity ($f/N=30\%$), increasing p from 20% to 40% can reduce the disagreement rate for $N=50$ nodes by approximately 19%. This demonstrates that consensus disagreements caused by random distribution can be effectively suppressed by appropriately configuring the committee ratio and increasing the network scale, thereby ensuring the robustness of the DC-PBFT protocol.

6.2. Robustness and Parameter Analysis

Given that disagreements trigger high-cost arbitration consensus, an increase in the disagreement rate inevitably leads to a decrease in overall system throughput and an increase in transaction latency. We experimentally quantify the interaction effect of two key parameters, the global Byzantine node ratio ($f/N$) and the committee ratio (p), on the actual performance of the DC-PBFT protocol. We fixed the total network size at $N=100$ and measured the throughput (TPS) and average transaction latency (Latency) under different global Byzantine node ratios and different committee ratios.

The experimental results are depicted in Figure 6. As the Byzantine node ratio increases, the throughput of all configurations trends downward, while latency correspondingly rises. However, the magnitude of this performance degradation is closely correlated with the committee ratio p. Under the $f/N=30\%$ condition, the $p=20\%$ configuration exhibits the poorest robustness, with its throughput dropping the fastest and its latency increasing the most significantly. In contrast, the $p=50\%$ configuration consistently demonstrates the highest throughput and the lowest latency. This also illustrates that small-scale committees are more susceptible to triggering high-cost arbitration under high attack intensity, leading to severe performance deterioration. Therefore, selecting a more balanced committee ratio is crucial for DC-PBFT to maintain high performance and stability in Byzantine environments.

Performance Boundary Analysis Under Worst-Case Scenarios To comprehensively evaluate the protocol’s robustness, we analyzed the performance degradation boundary of DC-PBFT under the worst-case scenario. The worst case occurs when the network experiences severe partition faults, or a few malicious nodes with high weights launch a suicide attack, intentionally causing a severe disagreement between the consensus committee and replica nodes, thereby forcing the entire network into the dispute arbitration phase. In this extreme state, the parallel optimization of DC-PBFT temporarily fails, and the protocol’s communication complexity boundary degrades to $O\left(N^2\right)$. At this point, the theoretical boundary for system throughput and latency will briefly drop to the baseline level of classic PBFT (e.g., in our experiment at $N=100$, the degradation boundary is approximately 158 TPS and 1.17 s latency, as shown in Figure 7). However, due to the protocol’s strict built-in penalty mechanism, the malicious nodes initiating the attack will be immediately evicted after the arbitration round is completed. Therefore, the performance penalty in the worst-case scenario is strictly confined to the current single consensus period, and the system will subsequently quickly recover to the efficient parallel consensus norm.

6.3. Scalability Analysis

To evaluate the scalability of DC-PBFT, we incrementally increased the total number of nodes under identical settings with no Byzantine nodes, assessing its TPS and consensus delay against the baseline protocols PBFT [4], HoneyBadgerBFT [13], and RepChain [23] under an ideal network condition with exactly zero Byzantine nodes ($f=0$, i.e., $f/N=0\%$). To guarantee a fair comparison, the baseline HoneyBadgerBFT was configured using the standard benchmark parameters from its official repository and original paper. Specifically, the ACS (Asynchronous Common Subset) subset size was set to 10 nodes, and the transaction batch size was set to 500 transactions per block. As depicted in Figure 8, while the throughput of all protocols declines and consensus latency rises with an increase in the number of nodes, the performance disparity widens. DC-PBFT consistently demonstrates significant advantages over all baseline algorithms in terms of both throughput and latency.

Compared to classic PBFT, PBFT’s communication complexity causes its performance to degrade sharply with growth. At $N=100$, PBFT’s average latency reaches 1.17 s, and its throughput drops to approximately 158 TPS. In contrast, DC-PBFT at $N=100$ still maintains a high throughput of approximately 1200 TPS and a low latency of 0.4 s. Even when compared to the similarly optimized RepChain and the censorship-resistant HoneyBadgerBFT, DC-PBFT exhibits a clear performance advantage. This indicates that DC-PBFT’s parallel grouping architecture effectively mitigates the communication bottleneck, demonstrating superior performance and scalability in medium-to-large network environments.

While our empirical simulation is bounded at $N=200$ due to hardware limitations, the scalability trend for larger networks (e.g., $N=500$ or $N=1000$) can be reliably projected through theoretical communication complexity. Classic PBFT’s message complexity grows quadratically at $O\left(N^2\right)$. In contrast, DC-PBFT’s parallel grouping decouples this into $O(N_c^2+N_r^2)$. For instance, in a hypothetical network of $N=1000$ with a committee ratio of $30\%$ ($N_c=300,N_r=700$), standard PBFT would generate messages proportional to 1,000,000. DC-PBFT, however, would generate messages proportional to ${300}^2+{700}^2=$ 580,000, achieving a $42\%$ theoretical reduction in network load. This mathematical divergence guarantees that as N scales further, the performance gap between DC-PBFT and baseline algorithms will continue to widen favorably.

To further explore the robustness and adaptability of DC-PBFT, we conducted a sensitivity analysis on the committee ratio p. Figure 7 comprehensively illustrates both the system’s throughput and latency across different p values (20%, 30%, 40% and 50%) with 95% confidence intervals.

The results reveal that $p=50\%$ serves as the optimal configuration for both performance and robustness. From a performance perspective, the total communication complexity is bounded by $O(N_c^2+N_r^2)$. When $p=50\%$, the network load is perfectly balanced between the Consensus Committee and the Replica Network, minimizing the quadratic communication overhead. As p decreases (e.g., to 20%), the Replica Network becomes overloaded with $80\%$ of the nodes, leading to severe local congestion, which drops the throughput to 850 TPS and spikes the latency to 0.65 s at $N=100$.

From a robustness perspective, a smaller p introduces a higher variance in the hypergeometric distribution during node election, increasing the risk of malicious nodes temporarily dominating the committee. Therefore, maintaining $p=50\%$ not only maximizes parallel efficiency but also minimizes the probability of triggering the high-cost global arbitration, demonstrating the protocol’s strong structural robustness.

6.4. Long-Term Stability Analysis

After introducing a reputation mechanism, merely testing the protocol’s short-term performance is insufficient. The core value of the reputation mechanism lies in its long-term effect—dynamically adjusting node influence based on historical behavior, thereby gradually purifying the consensus environment and improving the system’s long-term stability and performance under sustained attack. To evaluate the long-term effectiveness of the DC-PBFT reputation mechanism, we measured and compared the performance evolution of each protocol over time (measured by the number of blocks) in a malicious environment with a sustained presence of Byzantine nodes ($f/N=30\%$).

Specifically, the simulation spans a continuous duration of 300 blocks. To comprehensively evaluate the general effectiveness of the reputation mechanism against diverse attack patterns, the Byzantine nodes are programmed to execute a Mixed Byzantine Strategy. This includes random subsets of malicious nodes performing minor violations (e.g., node timeouts), moderate violations (e.g., passive non-voting), and severe safety attacks (e.g., double-signing). Furthermore, the reputation system dynamically responds to these behaviors using an event-driven update mechanism evaluated at each block’s finalization and period transition. The specific decay parameters applied in the simulation align with our theoretical incentive model: $w_{reward}=0.01$ for honest participation, and dynamic penalty weights of $w_{penalty}\in \{0.05,0.3,1.0\}$ corresponding to the severity of the detected violations.

The experimental results are shown in Figure 9. It can be clearly observed that the PBFT and HoneyBadgerBFT protocols, which lack a dynamic reputation mechanism, exhibit performance at a low, stable level throughout the entire runtime. PBFT’s throughput consistently fluctuates around 80 TPS, while HoneyBadgerBFT is around 150 TPS. Their respective latencies also remain stable at approximately 2.9 s and 2.3 s, with neither showing any performance improvement. In contrast, RepChain and DC-PBFT, which utilize reputation mechanisms, demonstrate significant self-recovery capabilities and long-term robustness. As the number of blocks increases, the reputation systems of both protocols take effect, continuously identifying and penalizing malicious nodes, thereby reducing their influence in consensus, such as DC-PBFT lowering the probability of low-reputation nodes being elected to the committee. This is also directly reflected in performance: RepChain’s throughput steadily increases from an initial 245 TPS to 505 TPS, an increase of over $100\%$; DC-PBFT’s throughput climbs from 673 TPS to 960 TPS. In terms of latency, RepChain’s latency is optimized from 2.1 s down to 1.1 s, while DC-PBFT’s latency decreases from 1.0 s to 0.6 s, remaining the lowest throughout.

This indicates that the reputation mechanism is critical for ensuring long-term stability under sustained attack. DC-PBFT not only exhibits superior robustness over all baseline algorithms in the initial phase of an attack, but its reputation mechanism also effectively drives system performance recovery to a higher level.

6.5. Censorship Resistance Analysis

To directly evaluate DC-PBFT’s core design objective, namely its ability to resist malicious censorship, we simulated targeted censorship attacks and measured the average confirmation latency accumulated by targeted transactions over 300 blocks. The two comparison setups were a $20\%$ probability of the Proposer being malicious and a $20\%$ probability of the Primary being malicious, respectively. When the Proposer was malicious, it would always ignore the target transactions; when the Primary was malicious, it would refuse to broadcast the block proposal containing the target transactions. We compare DC-PBFT’s performance under these two attacks against its baseline performance (no censorship) and against the censorship-resistant HoneyBadgerBFT in an environment with $20\%$ Byzantine nodes. Since the confirmation rate for targeted transactions in PBFT and RepChain approaches $0\%$ under such sustained malicious leader attacks, they were not included in this latency comparison chart.

The experimental results are depicted in Figure 10. The graph clearly illustrates the performance cost and scalability of different censorship resistance mechanisms. HoneyBadgerBFT, while guaranteeing a $100\%$ confirmation rate through threshold encryption, incurs high latency due to its inherent asynchronous nature and cryptographic overhead, reaching approximately 1.1 s at N = 100 and exhibiting the lowest performance among all scenarios. In contrast, the baseline performance of DC-PBFT is only 0.4 s at N = 100. When subjected to a Proposer censorship attack, the protocol recovers via the VRF role rotation mechanism at a low cost, with the average latency increasing only slightly to approximately 0.51 s at N = 100. When subjected to a Primary censorship attack, the protocol relies on the more costly view change mechanism to recover, causing the latency to increase to approximately 0.61 s at N = 100. It is noteworthy that the latency curve for the Primary attack scenario also has a slightly steeper slope than the Proposer attack scenario, indicating that the overhead of a view change is more sensitive to the total network size, N, than role rotation.

This experiment demonstrates that DC-PBFT successfully achieves its censorship resistance design goal, guaranteeing transaction liveness. Compared to HoneyBadgerBFT, DC-PBFT in an $N=100$ network reduces the latency cost of censorship resistance by approximately $45\%$ (vs. Primary attack) to $54\%$ (vs. Proposer attack). This clearly proves that DC-PBFT, through its decoupling and dynamic rotation mechanisms, achieves a superior balance between censorship resistance and system performance.

To evaluate the protocol’s resilience against complex, coordinated threats, we simulated the Cumulative Confirmation Rate of 1000 targeted transactions under three scenarios: Baseline (0% malicious), Scenario A (Proposer and Primary collude to censor), and Scenario B (30% of the Consensus Committee colludes and takes turns censoring).

As shown in

Table 3. Cumulative Confirmation Rate of Targeted Transactions under Different Collusion Scenarios.

Attack Scenario	Block 1	Block 2	Block 3	Block 4	Block 5	Final Status
Baseline (No Attack)	100%	100%	100%	100%	100%	100% Confirmed
Scenario (a) Proposer & Primary Collusion	0%	71.2%	99.8%	100%	100%	100% Confirmed
Scenario (b) 30% Committee Collusion	70.5%	91.3%	97.4%	99.2%	99.9%	100% Confirmed

, under Scenario A, the targeted transactions face a 100% censorship rate during the first block cycle since the colluding leaders control the proposal phase. However, due to the VRF-based dynamic role rotation, their monopoly is immediately broken in subsequent cycles, and the confirmation rate jumps to 99.8% by Block 3. Under Scenario B, the probability of continuous censorship decays exponentially. While the initial confirmation rate is reduced to 70.5% (proportional to the honest node ratio), the cumulative confirmation rate surpasses 99% by the 4th block.

These results mathematically and practically demonstrate that while collusion can cause predictable, short-term delays, the DC-PBFT protocol strictly guarantees a 100% final confirmation rate for all valid transactions.

7. Conclusions

This paper addresses the performance bottlenecks and IoT data censorship risks caused by the centralization of power in the classic PBFT consensus protocol. We designed and implemented DC-PBFT, a censorship-resistant BFT protocol tailored for Edge Computing. The core innovation of this protocol is the introduction of a power-balancing mechanism by decoupling the roles of the Proposer and the Primary, supplemented by VRF-based dynamic role rotation, which fundamentally eliminates the arbitrary power of any single node.

To support this architecture, we designed a parallel group consensus process where a Consensus Committee leads the consensus, and a Replica Network performs independent, parallel auditing. When a disagreement arises, the protocol guarantees final consistency through a global arbitration consensus. Furthermore, the protocol includes a complete incentive model. This model ensures incentive compatibility between node interests and network security by utilizing a hybrid election mechanism that combines PoS with dynamic reputation, as well as an economic reward system based on a dynamic relative share model and a tiered penalty mechanism.

It should be noted that the current empirical evaluation is subject to certain hardware and environmental constraints. Due to simulation hardware limitations, our node scale is bounded at 200 nodes. While the theoretical communication complexity analysis in Section 6.3 confirms the scalability advantage of the proposer-primary decoupling, practical performance in larger-scale environments remains to be further validated. Furthermore, the current evaluations are conducted in a controlled baseline network, whereas real-world Edge-IoT environments are typically characterized by severe network fluctuations and frequent node churn. Therefore, future research will primarily focus on three directions: (1) deploying DC-PBFT in more extensive distributed testbeds to evaluate large-scale performance limits; (2) integrating the protocol with advanced network emulators to rigorously test resilience and develop secure dynamic membership mechanisms under highly unstable, high-churn conditions; and (3) exploring more efficient, lightweight arbitration schemes.