Blockchain Epidemic Consensus Protocol (BECP)

• The paper introduces BECP as a leader-less, fully decentralized consensus protocol using epidemic (gossip-based) mechanisms for probabilistic convergence in large-scale systems.
• BECP is decomposed into sub-protocols (SSEP, NCP, and PTP) that manage system size estimation, random peer sampling, and local block stabilization through phase-transition tests.
• Experimental results show BECP achieves lower latency, reduced messaging overhead, and consistent throughput compared to protocols like Avalanche and PBFT.

Blockchain Epidemic Consensus Protocol (BECP) is a fully decentralised, leader-less blockchain consensus protocol proposed for large-scale and extreme-scale blockchain systems. In the 2025 descriptions of the protocol, BECP is presented as an epidemic, or gossip-based, consensus design that avoids fixed validators and leaders, relies on probabilistic convergence, and uses local phase-transition tests to decide when a candidate block should be committed. Its published formulations combine three sub-protocols—System Size Estimation Protocol (SSEP), Node Cache Protocol (NCP), and Phase Transition Protocol (PTP)—and report comparative evaluations against PAXOS, RAFT, PBFT, Avalanche, and Snowman (Abdi et al., 4 Aug 2025, Abdi et al., 4 Aug 2025).

1. Placement within epidemic blockchain consensus

BECP belongs to the family of epidemic consensus mechanisms, also described as sampling-based or gossip-based consensus. In this family, consensus departs from classical replicated-state-machine approaches such as PBFT and Raft by relying on randomized peer sampling and statistical decision processes rather than full-quorum votes. Nodes exchange information with small, randomly chosen peer sets over repeated rounds, and local estimates concentrate toward a common value as gossip proceeds (Auvolat et al., 2021).

Within that setting, BECP adopts the standard epidemic advantages emphasized in its own descriptions: no reliance on a fixed set of validators or leaders, probabilistic guarantees of convergence, efficient use of network resources, and tolerance to node and network failures (Abdi et al., 4 Aug 2025). One of the papers explicitly frames the protocol goal as the design of a “fully-decentralised, leader-less blockchain consensus protocol” that scales to $O(10^4)$ nodes and uses epidemic push–pull communication to disseminate block proposals, resolve forks, and detect convergence probabilistically (Abdi et al., 4 Aug 2025).

This positioning is important because BECP is not presented as a minor variation of a leader-based BFT protocol. Its design logic is instead closer to epidemic systems such as Avalanche and Snowman, but with a distinct reliance on single-peer gossip per cycle, local counter aggregation, and explicit local stability tests rather than $K$-sampling plus quorum thresholds (Abdi et al., 4 Aug 2025, Abdi et al., 4 Aug 2025).

2. Network model, assumptions, and protocol decomposition

The published BECP descriptions characterize the network as a peer-to-peer overlay in which each node maintains only a partial view of the system. In one formulation, the model is asynchronous: there is no global clock or round-synchrony, messages are delivered reliably with arbitrary but bounded delay in $[\Delta_{\min}, \Delta_{\max}]$, and the experiments instantiate $\Delta_{\min}=0.01\,s$ and $\Delta_{\max}=0.3\,s$. In another formulation, the network is described as partially synchronous with bounded message-delay distributions that may be uniform or Pareto (Abdi et al., 4 Aug 2025, Abdi et al., 4 Aug 2025).

BECP is decomposed into three intertwined sub-protocols. SSEP maintains a local estimate $\hat N_i$ of the current system size. NCP maintains a cache $C_i$ of peer identifiers and provides random neighbour sampling via getRandomNode(). PTP is the epidemic consensus engine that updates local counters and determines when a block has stabilized sufficiently to be committed (Abdi et al., 4 Aug 2025).

The fault model requires careful reading because the two descriptions are aligned on crash-stop and delay tolerance but not on a fully developed Byzantine model. One formulation states explicitly that no Byzantine faults are assumed and that all nodes are “benign”; only crash failures and arbitrary message reordering or delay are considered (Abdi et al., 4 Aug 2025). The other states that nodes are honest, with no Byzantine mis-reports, but possibly slow, and that up to $f$ “slow” or crash-stop nodes are tolerated; it then discusses Byzantine behaviour only as an extension and future direction rather than as the baseline protocol model (Abdi et al., 4 Aug 2025).

This means that BECP, as documented, is primarily a protocol for large-scale consensus under reliable delivery, delay, and crash-stop conditions, rather than a finished Byzantine consensus construction in the same sense as classical BFT protocols.

3. State variables and gossip-cycle mechanics

Each node runs a repeated epidemic cycle. In the concise formulation, at local cycle $k$ and cycle-time $\tau$, node $K$0 samples one peer $K$1, exchanges its local vote-counter tuple

$K$2

merges the received counters by addition, and computes a local estimate

$K$3

If $K$4 for $K$5 consecutive cycles, the node decides on the current candidate block $K$6, transitions to COMMIT, and garbage-collects other candidates (Abdi et al., 4 Aug 2025).

The more elaborate formulation expands the same design into explicit blockchain state. Each node maintains a confirmed ledger, a cache $K$7 of candidate blocks, and a current preferred block $K$8. For each candidate block $K$9, the node stores the block sequence number $[\Delta_{\min}, \Delta_{\max}]$0, creator identifier $[\Delta_{\min}, \Delta_{\max}]$1, creation timestamp $[\Delta_{\min}, \Delta_{\max}]$2, two counter pairs $[\Delta_{\min}, \Delta_{\max}]$3 and $[\Delta_{\min}, \Delta_{\max}]$4, and a block state

$[\Delta_{\min}, \Delta_{\max}]$5

Messages MSG_PUSH and MSG_PULL piggy-back both new block proposals and estimator values for each $[\Delta_{\min}, \Delta_{\max}]$6 (Abdi et al., 4 Aug 2025).

In that second description, nodes may generate a new block every $[\Delta_{\min}, \Delta_{\max}]$7 with probability $[\Delta_{\min}, \Delta_{\max}]$8, referencing the current preferred block $[\Delta_{\min}, \Delta_{\max}]$9. Fork resolution is handled by comparing blocks with the same sequence number and, when origins differ, breaking ties by timestamp and then proposer identifier. The routine forkResolution(τ) recursively removes descendants of a replaced fork (Abdi et al., 4 Aug 2025).

Taken together, the two descriptions indicate a common design pattern: epidemic dissemination carries both candidate blocks and lightweight counters, while local state machines infer convergence from the evolution of those counters rather than from explicit global rounds or all-to-all certification.

4. Decision rules, convergence, and asymptotic bounds

The most explicit convergence statement appears in the theorem-style analysis. Under the asynchronous, reliable-delivery model, BECP is stated to commit on a single block $\Delta_{\min}=0.01\,s$0 at all non-failed nodes within

$\Delta_{\min}=0.01\,s$1

cycles, with probability at least $\Delta_{\min}=0.01\,s$2 for any fixed $\Delta_{\min}=0.01\,s$3 (Abdi et al., 4 Aug 2025).

The same source gives the corresponding asymptotic bounds: $\Delta_{\min}=0.01\,s$4 for wall-clock consensus latency, and

$\Delta_{\min}=0.01\,s$5

for total message complexity until commit. Throughput is described as asymptotically independent of $\Delta_{\min}=0.01\,s$6, namely $\Delta_{\min}=0.01\,s$7, because new proposals can proceed in parallel (Abdi et al., 4 Aug 2025).

A second analysis presents the same behaviour through standard push–pull epidemic dissemination. If each node contacts one random peer per round, then for any $\Delta_{\min}=0.01\,s$8,

$\Delta_{\min}=0.01\,s$9

implies that the probability all honest nodes have seen a given block by round $\Delta_{\max}=0.3\,s$0 is at least $\Delta_{\max}=0.3\,s$1. After separate propagation and agreement phases, the joint convergence probability is stated as at least $\Delta_{\max}=0.3\,s$2, yielding very high-probability finality in $\Delta_{\max}=0.3\,s$3 cycles (Abdi et al., 4 Aug 2025).

These analyses are consistent at the level of asymptotic structure. Both formulations treat logarithmic epidemic spread as the core mechanism, and both attach finality to a local criterion: either repeated stability of the estimator $\Delta_{\max}=0.3\,s$4 or threshold-based state transitions across PROPAGATED, AGREED, and COMMITTED.

5. Experimental evidence and reported performance

The reported evaluations use the JABS Java simulator and compare BECP against classical protocols and epidemic baselines. One study evaluates $\Delta_{\max}=0.3\,s$5 with $\Delta_{\max}=0.3\,s$6, $\Delta_{\max}=0.3\,s$7, $\Delta_{\max}=0.3\,s$8, $\Delta_{\max}=0.3\,s$9, $\hat N_i$0, and $\hat N_i$1. Another evaluates $\hat N_i$2 with cycle $\hat N_i$3, $\hat N_i$4, $\hat N_i$5, $\hat N_i$6, $\hat N_i$7, and $\hat N_i$8 (Abdi et al., 4 Aug 2025, Abdi et al., 4 Aug 2025).

At $\hat N_i$9, one paper reports the following BECP-versus-Avalanche comparison (Abdi et al., 4 Aug 2025):

Metric	Avalanche	BECP
Throughput (items/s)	0.080	0.096
Latency (s)	101.92	21.34
Msgs per 600 s	85.6 M	8.6 M

The same study summarizes these differences as $C_i$0 higher throughput, $C_i$1 better average consensus latency, and a $C_i$2 reduction in messages relative to Avalanche at $C_i$3 (Abdi et al., 4 Aug 2025). Across $C_i$4 to $C_i$5 nodes, it further reports that BECP throughput is flat at approximately $C_i$6 blocks per $C_i$7, Avalanche is approximately $C_i$8, and BECP latency remains approximately $C_i$9 while Avalanche remains approximately $f$0 (Abdi et al., 4 Aug 2025).

The second paper reports throughput of approximately $f$1 blocks/s, latency around $f$2 to $f$3 for $f$4 to $f$5, and correctness under Pareto delay scenarios with $f$6, while Avalanche incurs failures or throughput drops at $f$7 (Abdi et al., 4 Aug 2025). It also reports message counts for BECP ranging from $f$8 at $f$9 to $k$0 at $k$1, contrasted with PBFT values from $k$2 to $k$3 over the same range (Abdi et al., 4 Aug 2025).

A notable point is that the strongest empirical advantage is consistently reported against Avalanche and PBFT-class overhead. One latency table in the second paper lists RAFT/PAXOS at $k$4 and PBFT at $k$5, whereas BECP is reported near $k$6 on those experiments (Abdi et al., 4 Aug 2025). Accordingly, the evidence in the published descriptions supports BECP most directly as a scalable epidemic protocol with low communication overhead and competitive large-network performance, rather than as a universally lower-latency protocol across all possible baselines.

6. Peer sampling, limitations, and open directions

Epidemic consensus depends fundamentally on peer sampling. A separate line of work on epidemic blockchain consensus states that a Secure Random Peer Sampling service is at the heart of any epidemic consensus algorithm and identifies diversity, low Byzantine fraction, and connectivity as the core goals, with Sybil attacks, Eclipse attacks, collusion, and flooding as principal threats (Auvolat et al., 2021).

BECP assumes that NCP provides a uniform random sample of peers, but the 2025 BECP descriptions do not center on adversarial peer-sampling hardening. One formulation states that NCP provides a uniform random sample of size NCACHE from the existing membership; another assumes a connected overlay and honest nodes with no Byzantine mis-reports (Abdi et al., 4 Aug 2025, Abdi et al., 4 Aug 2025). This suggests that BECP’s published results are conditioned on a benign or crash-stop environment in which random-neighbour sampling is available as a service rather than established as a security theorem.

That distinction matters because other epidemic blockchain work, such as BASALT, focuses precisely on secure peer sampling under adversarial pressure and proposes IP-prefix-based methods to reduce over-representation and Eclipse risk (Auvolat et al., 2021). A plausible implication is that a production-grade permissionless deployment of epidemic blockchain consensus would need both a consensus engine of the BECP type and a secure random peer-sampling substrate of the BASALT type, although that integrated construction is not provided in the BECP descriptions.

The open research agenda is stated directly in the larger-scale BECP paper: Byzantine-resistant extensions, such as weighted gossip and signature aggregation; adaptive $k$7 and $k$8 for variable network sizes and delay regimes; cross-shard consensus by multi-topic epidemic; and formal proofs of safety and liveness under Byzantine partial synchrony (Abdi et al., 4 Aug 2025). These directions identify the present boundary of the protocol family: BECP is documented as an epidemic, leader-less consensus design with logarithmic dissemination and $k$9 communication, but its Byzantine model, security composition with peer sampling, and deployment-level finality guarantees remain open areas of investigation.