{"id":"df9772bb-531a-4586-9e8b-dc10fb37a932","arxiv_id":"2508.02552","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"BECP adapts earlier epidemic agreement protocols to blockchains using a preferred-block fork resolution rule; simulations show near-constant throughput around 0.096 blocks/s and logarithmic message growth up to 10,000 nodes.","lead":"Blockchain Epidemic Consensus Protocol (BECP) combines three epidemic-style algorithms so nodes reach agreement by exchanging messages with a single random neighbor rather than a large sample. The authors run simulations up to 10,000 nodes and report throughput close to leader-based protocols with lower message overhead than Avalanche or Snowman.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Algorithm 1 line 12 replaces Bpref based on creator equality rather than parent identity, so a late sibling block can displace a confirmed block and break ledger consistency.","rationale":"The reader's conditional accept is correct in disposition, but the reason is sharper than 'missing formal proof': the modified Resolve Duplicate Block ID procedure has a concrete safety leak. Section 3 states that nodes create new blocks by referencing Bpref, and Algorithm 3 generates children of Bpref, so the intended acceptance test for a new block should be that its parent is Bpref or a consistent ancestor. Algorithm 1 line 12 instead compares only the creator of the parent with the creator of Bpref, which admits blocks that fork from an older ancestor created by the same proposer. This matters because fork handling is the only mechanism separating BECP from the original PTP, and the Section 4.3 correctness check merely follows block hashes over five trials under non-adversarial random message schedules. A deterministic schedule with a delayed sibling block after commit is within the stated delay-tolerance assumptions and would trigger the weak branch, breaking the single-chain invariant. This is an internal correctness issue, not a disagreement with external consensus or a parameter concern. A corrected condition (parent equality or ancestor check) plus a proof or invariant that no confirmed block can be displaced would restore the central claim. Thus I keep the reader's conditional verdict but recommend that the acceptance condition explicitly require fixing Algorithm 1 and demonstrating the fix in simulation or proof.","tokens_in":11472,"tokens_out":14521,"duration_ms":196475,"concrete_test":"Add a simulator trace assertion that records every execution of Algorithm 1 line 12 where τ′.parent != Bpref, and run a deterministic three-node delay scenario: node A creates b1 and then b2 referencing b1; node B commits b2 and a descendant; node C, still preferring b1, creates b3 referencing b1; deliver b3 to B after b2 is committed. If the literal creator-equality condition is used, B adopts b3 and the block-hash connectivity check fails; if the implementation instead requires parent equality, the published pseudocode does not match the evaluated protocol and must be corrected before any convergence claim is assessed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that BECP preserves PTP convergence and ledger consistency, and the load-bearing component is the revised Resolve Duplicate Block ID procedure (Algorithm 1). As written, Algorithm 1 does not enforce chain extension. Line 12 accepts a non-duplicate block τ′ and sets Bpref ← τ′ whenever creator(parent(τ′)) == creator(Bpref). This condition is strictly weaker than parent(τ′) == Bpref: any block whose parent was created by the same proposer as the current preferred block passes, including a sibling branch off an older ancestor. No confirmation check guards this branch, so a late-arriving sibling can displace a Bpref that already has committed descendants; Algorithm 2 then recursively discards those descendants from the cache. This is an internal correctness gap in the mechanism intended to guarantee a single consistent parent chain, exactly the property the five-trial hash-following correctness test checks. The published experiments do not include a scenario in which a sibling block arrives after the competing branch has been committed, and no formal invariant rules it out. The duplicate-replacement branch (lines 6–9) has the same absence of a committed-descendant check before forkResolution is called.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes BECP, a leaderless blockchain consensus protocol built on three existing epidemic protocols: SSEP, NCP, and PTP. The contribution is a modification of PTP's duplicate-block resolution through a preferred-block variable Bpref (Algorithm 1), a fork-resolution procedure (Algorithm 2), and a block-generation rule (Algorithm 3). The protocol is evaluated in the JABS simulator against PAXOS, RAFT, PBFT, Avalanche, and Snowman for networks of 1,000 to 10,000 nodes, under normal and delayed-message conditions. The paper claims probabilistic convergence, low communication overhead, tolerance to message delays, and throughput comparable to classical protocols, with experimental results interpreted as validating ledger consistency and correctness.","tokens_in":11631,"tokens_out":4616,"duration_ms":56064,"significance":"If the correctness and efficiency claims hold, BECP would be a useful addition to the epidemic-consensus literature, particularly for combining size estimation, random peer sampling, and phase-transition agreement without a leader. The paper includes concrete pseudocode, a reasonably large simulation study, and comparisons to relevant baselines. The central weakness is that the load-bearing safety and convergence properties are not established: the modifications to PTP are not accompanied by a correctness argument, the only validation is a five-trial hash-following test, and the implementation relies on a membership service that the paper itself admits is simulation-only. As it stands, the evidence is insufficient to support the abstract's claims of validated correctness and throughput gains.","major_comments":[{"comment":"The replacement condition in line 12 is creator(parent(τ′)) == creator(Bpref), which is strictly weaker than requiring parent(τ′) == Bpref. A late-arriving sibling block whose parent was created by the same proposer as Bpref can therefore replace Bpref even if Bpref has already been extended or confirmed. The surrounding text states that the current preferred block and its descendants are removed via Algorithm 2, but Algorithm 1 does not call forkResolution in this branch, so the pseudocode is internally inconsistent. No invariant or proof rules out the late-sibling displacement, and the correctness test in Section 4.3 does not construct such a scenario. Because this branch is the mechanism intended to maintain a single parent chain, ledger consistency is not established.","section":"Section 3, Algorithm 1"},{"comment":"The paper inherits the probabilistic convergence guarantees of PTP, SSEP, and NCP from earlier self-cited work without re-deriving them, yet Algorithms 1 and 3 change PTP's resolution and block-generation behavior. There is no theorem stating the conditions under which BECP converges to a single chain, no proof that Bpref updates preserve the PTP estimator invariants, and no analysis of how the new block-generation rule interacts with the agreement phase. Since the abstract's central claim is probabilistic convergence and correctness, this missing formal support is load-bearing rather than a presentation issue.","section":"Section 3"},{"comment":"The correctness validation is too weak to support the claim that simulations 'validated ledger consistency and correctness.' The test runs only five trials, checks connectivity by following block hashes, and reports no adversarial fork scenarios, no late-sibling arrivals, no chain-prefix agreement metric, and no statistical confidence. In addition, Table 5 is captioned as 5,000 nodes while Section 5.3 states it reports BECP for 10,000 nodes, and the entries are identical to Table 4; this inconsistency undermines confidence in the experimental record.","section":"Section 4.3 and Tables 4-5"},{"comment":"The implementation relies on NCP for random neighbor selection, and the paper explicitly states that NCP can only be used in simulations because nodes randomly select neighbors from a global list of known node IDs. This conflicts with the 'fully decentralised' claim and means the reported scalability and overhead results assume global knowledge at initialization. The suggested remedy, integrating EMP+ or another membership protocol, is not implemented or evaluated, so the extent to which the measured performance transfers to a realistic decentralized deployment is unknown.","section":"Sections 3 and 4.2"},{"comment":"The abstract's claim of throughput gains over existing epidemic-based approaches is not supported by the reported results. Figure 2 shows that BECP, RAFT, PBFT, and Snowman have identical throughput across all node counts, and Section 5.2 states only that BECP is 'slightly better' than Avalanche. The experimental evidence supports a claim of throughput parity with Snowman, not a gain, unless the authors specify a different comparison basis.","section":"Abstract and Section 5.2"},{"comment":"The stated network model is 'messages are never lost, nodes are honest, and an active node remains on throughout the cycle,' which is stronger than the abstract's claim of 'tolerance to message delays.' The delay experiments vary latency distributions but do not test message loss, node churn, or Byzantine behavior. The manuscript should either weaken the claimed tolerance or extend the evaluation to cover the assumptions that are actually claimed.","section":"Section 3"}],"minor_comments":[{"comment":"Table 5's caption says '5,000 nodes' while Section 5.3 says the table reports BECP for a 10,000-node network. The caption and text should be reconciled, and the duplicated numerical entries with Table 4 should be checked.","section":"Table 5 and Section 5.3"},{"comment":"The x-axis of Figure 7 labels the largest network size as '100000' (one hundred thousand), while the text and Section 4.2 state the maximum is 10,000 nodes. The axis label should be corrected.","section":"Figure 7"},{"comment":"Algorithm 3 uses the variable B_p without definition, while the text and Algorithm 1 use Bpref. The condition '∀B∈C_b, B.id≠B_p.id+1' and the prose 'verify that there is no other block of a greater ID than Bpref' should be aligned, since they describe different checks.","section":"Algorithm 3"},{"comment":"The notation 'Failed(0)/29' is ambiguous: it could mean zero failed trials out of five, zero failed blocks out of 29, or something else. The table headers and captions should define the reported quantity explicitly.","section":"Tables 4-5"}],"recommendation":"major_revision","confidential_remarks":"The paper is honest about the simulation-only status of NCP and about inheriting guarantees from prior work, but the Algorithm 1 safety gap is serious and must be addressed before the correctness claims can be accepted. I recommend major revision rather than rejection because the issue could be repaired by strengthening the replacement condition and adding a proof or a targeted adversarial simulation; however, if the authors cannot supply either, the manuscript should not be published as a validation of BECP."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things you should know about arXiv:2508.02552. The genuinely new part is the Bpref mechanism: nodes pick a preferred block and generate new blocks on top of it without waiting for confirmation, with a fork-resolution procedure for duplicates. That is a reasonable design idea, and the simulations are extensive—BECP runs at 10,000 nodes, holds throughput around 0.096 blocks/s, and sends fewer messages than Avalanche or Snowman while matching their latency. Credit where due: the authors build honestly on their own SSEP/NCP/PTP line and they include delay-tolerance experiments with Pareto message latencies.\n\nThe problem is that the safety argument for Bpref does not survive a close reading. In Algorithm 1, line 12, a non-duplicate block τ′ is accepted as the new preferred block whenever creator(parent(τ′)) equals creator(Bpref). That is strictly weaker than requiring parent(τ′) == Bpref. A late-arriving block whose parent was created by the same node as Bpref—but is actually a sibling branch off an older ancestor—passes the test. There is no check for whether Bpref already has committed descendants. If Bpref has been extended and then confirmed, accepting such a sibling will overwrite the preferred block and, per the paper's own description, discard the confirmed descendants from the cache. The ledger on different nodes can then permanently disagree. Worse, the pseudocode never calls forkResolution in this non-duplicate branch, even though the text says a new preferred block should remove the old one and its descendants. That is an internal contradiction between the algorithm and its description.\n\nWhat else is soft: the correctness validation is only five trials of following block hashes, with no scenario for a late sibling after commit; there is no sensitivity analysis for ε, Ψ, or Ncache; and no code or data are released. The abstract overstates throughput \"gains\" while Figure 2 actually shows BECP matching Raft and PBFT rather than beating them. These are secondary, but they add to the picture of a promising but under-validated result.\n\nSo my take: this is a serious research direction with a concrete, fixable algorithmic flaw. The paper is worth a real referee, but I would not accept it anywhere near as-is. The authors need to fix the condition to parent(τ′) == Bpref, add a confirmation guard, prove the modified PTP preserves convergence, and make the simulations reproducible. For your own reading, it's a good case study in why probabilistic epidemic consensus claims need formal invariants, but I wouldn't cite the safety results yet.","headline":"The BECP paper has a useful simulation study and a serious new idea, but Algorithm 1's preferred-block rule is unsafe as written—it can overwrite confirmed blocks—so the result is promising but not yet sound.","tokens_in":12220,"tokens_out":6933,"would_cite":false,"duration_ms":78929,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper introduces BECP, a fully decentralized leaderless epidemic consensus protocol for blockchains that claims probabilistic convergence, efficient message dissemination, and tolerance to message delays.","keywords":["blockchain consensus","epidemic protocol","gossip dissemination","leaderless consensus","probabilistic convergence","scalability","fork resolution","distributed ledger"],"falsifier":"Run the protocol for many trials under adversarial message scheduling where two conflicting blocks with the same ID arrive at different nodes in opposing orders, and track every node's committed ledger by following block hashes; a single trial in which two nodes commit different blocks sharing an ancestor, or in which the hash-chain test fails, would refute the safety claim.","tokens_in":11192,"feed_emoji":"🔗","tokens_out":5350,"duration_ms":57066,"temperature":0.7,"pith_summary":"This paper introduces Blockchain Epidemic Consensus Protocol (BECP), a fully decentralised, leaderless consensus protocol for blockchain networks. BECP replaces fixed validators and dense peer sampling with epidemic push/pull communication between randomly contacted neighbours, and it uses per-block estimator pairs to detect early convergence. The paper claims this yields probabilistic convergence, tolerance to message delays, and constant throughput of about 0.096 blocks per second in simulations up to 10,000 nodes, while sending fewer messages than Avalanche and Snowman and matching the throughput of Raft and PBFT. The significance would be a blockchain consensus mechanism that scales without a leader bottleneck or expensive sampling.","feed_headline":"Epidemic consensus holds throughput steady at 10,000 nodes","feed_subtitle":"No leader, no polling: BECP matches Raft and PBFT throughput with far fewer messages and survives heavy-tailed delays.","key_machinery":"The central mechanism is the pairing of epidemic estimators with blockchain structure. Each node maintains two estimator pairs (vp, wp) and (va, wa) per block, used to estimate how many nodes received the block in propagation and agreement phases; when these estimates approach the SSEP system-size estimate within error threshold epsilon for Psi consecutive cycles, the block is committed. The load-bearing addition is Algorithm 1's preferred block Bpref, which decides among duplicate blocks by generation time and proposer ID, together with Algorithm 2's recursive fork resolution and Algorithm 3's block generation guard.","core_discovery":"BECP combines three parallel protocols: SSEP estimates the current system size, NCP supplies random neighbour selection for epidemic communication, and PTP carries out consensus through propagation and agreement phases, comparing two estimator pairs per block against the estimated system size to decide when a block is confirmed. To make the underlying phase-transition protocol safe on a chain, the paper adds a revised Resolve Duplicate Block ID procedure that maintains a current preferred block Bpref and forks away conflicting blocks, plus a block generation rule that only creates a new block referencing Bpref when no higher-ID block is already known. The authors report that this construction produces ledger consistency confirmed by a hash-following test, near-constant throughput around 0.096 blocks/s, roughly logarithmic message growth, and stable latency near the 10-second block interval for networks from 1,000 to 10,000 nodes, outperforming Avalanche and Snowman in message efficiency while matching classical protocols in throughput.","pith_inferences":["If BECP's convergence guarantee holds beyond the simulator, the protocol suggests that epidemic push/pull aggregation can replace stochastic sampling as the engine of probabilistic consensus, cutting message complexity from O(k) per decision to O(1) per contact.","The observed consensus latency near 10 seconds likely tracks the block-generation interval rather than the agreement process; a testable extension is to shorten Tblock and check whether latency falls proportionally or hits a protocol floor.","The paper's assumptions preclude node crashes, message loss, and Byzantine behaviour; a natural next experiment is to inject fail-stop nodes and see whether the hash-chain correctness test survives, since the protocol is advertised as able to detect failures in future work.","Because NCP currently presumes a global list at initialisation, deployment in a permissionless setting would need a membership service such as EMP+; testing BECP with dynamic membership is an open extension."],"forward_implications":["BECP should reach consensus on a single chain in networks up to 10,000 nodes with throughput near 0.096 blocks/s regardless of network size.","Communication overhead grows only logarithmically with node count, in contrast to the repeated K-peer sampling of Avalanche and Snowman.","A BECP system can tolerate heavy-tailed message delays (Pareto with shape alpha 4 to 8) without throughput loss or failed hash-chain tests in the simulated settings.","Because no leader is elected and no validator set is fixed, BECP removes the single point of failure and the bottleneck that limits Paxos, Raft, and PBFT.","Block generation and confirmation need not be sequential: nodes can propose new blocks referencing the current preferred block before the previous block is confirmed."],"supporting_citations":[{"why":"supplies the System Size Estimation Protocol and the Phase Transition Protocol whose estimators BECP inherits.","marker":"[1]"},{"why":"provides the symmetric push-sum aggregation method used for the node cache and estimator updates.","marker":"[3]"},{"why":"gives the gossip-based aggregate computation behind epidemic estimator convergence.","marker":"[9]"},{"why":"provides the discrete-event blockchain simulator used for the comparative experiments.","marker":"[27]"},{"why":"defines the Snow family and Avalanche baseline that BECP is compared against.","marker":"[22]"},{"why":"defines the Frosty/Snowman baseline used in the message-delay comparison.","marker":"[4]"}],"fun_headline_variants":["BECP: no leader, epidemic consensus scales to 10k","Epidemic consensus matches classical throughput at scale","BECP: fewer messages, same throughput as Raft and PBFT","No-leader epidemic consensus handles heavy-tailed delays","BECP: logarithmic messaging for 10k-node blockchain"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol converges only if the revised duplicate-block resolution and block-generation rules preserve the original phase-transition agreement guarantee; the paper assumes this rather than proving it, and its network model also assumes messages are never lost, nodes are honest, and active nodes never leave mid-cycle.","fun_headline_variants_meta":{"raw":{"variants":["BECP: no leader, epidemic consensus scales to 10k","Epidemic consensus matches classical throughput at scale","BECP: fewer messages, same throughput as Raft and PBFT","No-leader epidemic consensus handles heavy-tailed delays","BECP: logarithmic messaging for 10k-node blockchain"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000845,"raw_usage":{"total_tokens":3673,"prompt_tokens":931,"completion_tokens":2742,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":547,"completion_tokens_details":{"reasoning_tokens":2657}},"tokens_in":547,"tokens_out":2742,"duration_ms":23170,"temperature":1.0,"reasoning_tokens":2657,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T04:56:52.340467+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the protocol for many trials under adversarial message scheduling where two conflicting blocks with the same ID arrive at different nodes in opposing orders, and track every node's committed ledger by following block hashes; a single trial in which two nodes commit different blocks sharing an ancestor, or in which the hash-chain test fails, would refute the safety claim.","supporting_citations":[{"cited_title":"Agreement in epidemic infor- mation dissemination","cited_arxiv_id":null,"evidence_quote":"supplies the System Size Estimation Protocol and the Phase Transition Protocol whose estimators BECP inherits."},{"cited_title":"Sym- metric push-sum protocol for decentralised aggregation","cited_arxiv_id":null,"evidence_quote":"provides the symmetric push-sum aggregation method used for the node cache and estimator updates."},{"cited_title":"Gossip-based computation of ag- gregate information","cited_arxiv_id":null,"evidence_quote":"gives the gossip-based aggregate computation behind epidemic estimator convergence."},{"cited_title":"Jabs: A blockchain simu- lator for researching consensus algorithms.IEEE Transactions on Network Science and Engineering, 2023","cited_arxiv_id":null,"evidence_quote":"provides the discrete-event blockchain simulator used for the comparative experiments."},{"cited_title":"Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies.Available [online].[Accessed: 4-12-2018], 2018","cited_arxiv_id":null,"evidence_quote":"defines the Snow family and Avalanche baseline that BECP is compared against."},{"cited_title":"Frosty: Bringing strong liveness guarantees to the Snow family of consensus protocols","cited_arxiv_id":"2404.14250","evidence_quote":"defines the Frosty/Snowman baseline used in the message-delay comparison."}],"review_version":1}