Pith. sign in

REVIEW 6 major objections 4 minor 27 references

Blockchain Epidemic Consensus for Large-Scale Networks

T0 review · 6 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2508.02552 v1 pith:3A2VTNPJ submitted 2025-08-04 cs.DC

Siamak Abdi , Giuseppe Di Fatta , Atta Badii , Giancarlo Fortino This is my paper · ORCID
classification cs.DC
keywords blockchainconsensusepidemicprotocolgossipdisseminationleaderlessprobabilisticconvergencescalabilityforkresolutiondistributedledger
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

6 major / 4 minor

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.

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 (6)
  1. [Section 3, Algorithm 1] 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.
  2. [Section 3] 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.
  3. [Section 4.3 and Tables 4-5] 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.
  4. [Sections 3 and 4.2] 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.
  5. [Abstract and Section 5.2] 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.
  6. [Section 3] 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.
minor comments (4)
  1. [Table 5 and Section 5.3] 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.
  2. [Figure 7] 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.
  3. [Algorithm 3] 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.
  4. [Tables 4-5] 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.

Circularity Check

2 steps flagged · score 4.0 of 10

BECP's probabilistic-convergence guarantee is inherited from self-cited PTP/SSEP/NCP work, but the blockchain-specific algorithms and simulations are new; no fitted-prediction circularity was found.

  1. self citation load bearing [Section 3, first and third paragraphs (The BECP Consensus Protocol)]
    "BECP consists of three intertwined protocols that run in parallel: the System Size Estimation Protocol (SSEP) [1], the Node Cache Protocol (NCP) [3], and the Phase Transition Protocol (PTP) [1]. ... Finally, the PTP is a decentralised consensus algorithm that takes advantage of the other two protocols and eliminates duplicate issues and ensures the correct ordering of IDs within blocks."

    The paper's headline property 'probabilistic convergence' is not re-derived or formally verified in this paper; it is stated as a property of PTP, and PTP is reference [1], a prior paper by overlapping authors (Ayiad, Katti, Di Fatta). The only in-paper correctness evidence is the five-trial hash-following simulation (Section 4.3), which does not independently establish the epidemic convergence guarantee. Thus the load-bearing correctness claim reduces to a self-citation rather than to a proof or to an external, machine-checked result.

  2. self citation load bearing [Section 3, paragraph after the PTP description]
    "The main benefit of comparing estimators to the system size is that it enables the detection of early convergence in the estimates(vp/wp)and(va/wa), improving throughput and consensus time [1]."

    BECP's claimed throughput and latency advantage over Avalanche/Snowman is attributed to [1]'s early-convergence detection. The underlying estimator convergence is from the same self-cited PTP work, and no proof or independent reproduction is supplied in this paper. The empirical results are new, so this is partial rather than complete circularity.

full rationale

No step was found in which a fitted parameter is renamed a prediction: the BECP parameters (epsilon, Psi, Ncache, Tblock) are fixed configuration values, and the reported throughput, latency, and message counts are direct simulation outputs. The comparison against PAXOS, RAFT, PBFT, Avalanche, and Snowman is an external benchmark, and the correctness test follows block hashes rather than being fitted to the claimed result. The main circularity is the inherited PTP/SSEP/NCP convergence guarantee: the paper defines BECP as a composition of these protocols and then treats their convergence properties as established by self-authored references [1] and [3], without re-deriving or independently verifying them. This makes the central probabilistic-convergence claim partially self-citational. The sibling-block replacement concern in Algorithm 1 and the strong assumptions of no message loss and honest nodes are correctness and validity issues, not circularity, and therefore do not further raise the score.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim of convergence and correctness rests on self-cited prior epidemic protocols and on idealized network assumptions. Three protocol parameters (epsilon, Psi, Ncache) are free choices without sensitivity analysis. No new physical or computational entities are postulated beyond the protocol variable Bpref.

free parameters (3)
  • estimation error threshold epsilon = 0.05
    BECP convergence detection threshold; set without sensitivity analysis in the paper.
  • minimum consecutive cycles Psi = 5
    Number of consecutive cycles required for convergence confirmation; chosen without justification or sensitivity study.
  • neighbor cache size Ncache = 100
    Size of the local membership cache used by NCP; set in Table 1 without analysis of its effect on results.
assumptions (3)
  • domain assumption PTP, SSEP, and NCP from references [1], [2], [3], and [9] provide the stated probabilistic convergence and aggregation guarantees.
    The paper assumes these guarantees carry over to BECP; they are not re-proven or formally verified here.
  • domain assumption The network is connected, messages are never lost, nodes are honest, and active nodes remain active throughout a cycle.
    Explicitly stated in Section 3; this is stronger than the 'tolerance to message delays' claim and excludes Byzantine faults and churn.
  • ad hoc to paper The correctness test that follows block hashes across nodes is sufficient to detect consensus failures.
    Section 4.3 defines the test; it checks chain connectivity only and is run for five trials, giving weak evidence of safety or liveness.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Blockchain Epidemic Consensus for Large-Scale Networks." pith.science (2026). https://pith.science/paper/3A2VTNPJ

@misc{pith2026250802552,
  author       = {Pith},
  title        = {Pith review of: Blockchain Epidemic Consensus for Large-Scale Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3A2VTNPJ}},
  note         = {Machine review of arXiv:2508.02552}
}
read the original abstract

Blockchain is a distributed ledger technology that has applications in many domains such as cryptocurrency, smart contracts, supply chain management, and many others. Distributed consensus is a fundamental component of blockchain systems that enables secure, precise, and tamper-proof verification of data without relying on central authorities. Existing consensus protocols, nevertheless, suffer from drawbacks, some of which are related to scalability, resource consumption, and fault tolerance. We introduce Blockchain Epidemic Consensus Protocol (BECP), a novel fully decentralised consensus protocol for blockchain networks at a large scale. BECP follows epidemic communication principles, without fixed roles like validators or leaders, and achieves probabilistic convergence, efficient message dissemination, and tolerance to message delays. We provide an extensive experimental comparison of BECP against classic protocols like PAXOS, RAFT, and PBFT, and newer epidemic-based protocols like Avalanche and Snowman. The findings indicate that BECP provides desirable gains in throughput, consensus latency, and substantial message-passing efficiency compared to existing epidemic-based approaches, validating its usability as an effective and scalable approach for next-generation blockchain systems.

Figures

Figures reproduced from arXiv: 2508.02552 by the authors.

Figure 1
Figure 1. Illustration of Protocol Immutability (Case I), Fork Resolution (Case II): White blocks [PITH_FULL_IMAGE:figures/full_fig_p011_1.png] view at source ↗
Figure 2
Figure 2. Comparative Throughput Analysis: BECP, RAFT, PAXOS, PBFT, Snowman, and [PITH_FULL_IMAGE:figures/full_fig_p017_2.png] view at source ↗
Figure 3
Figure 3. Comparative communication overhead of BECP, RAFT, PAXOS, PBFT, Snowman, [PITH_FULL_IMAGE:figures/full_fig_p018_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Comparative analysis of average consensus latency for node counts ranging from 1,000 [PITH_FULL_IMAGE:figures/full_fig_p018_4.png]
Figure 5
Figure 5. Figure 5: Analysis of throughput, measured in blocks per second, for node counts ranging from [PITH_FULL_IMAGE:figures/full_fig_p019_5.png]
Figure 6
Figure 6. Figure 6: Analysis of communication overhead, measured in total number of sent messages [PITH_FULL_IMAGE:figures/full_fig_p019_6.png]
Figure 7
Figure 7. Figure 7: Analysis of average consensus latency for node counts ranging from 1,000 to 10,000 [PITH_FULL_IMAGE:figures/full_fig_p020_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

27 extracted references · 25 canonical work pages

  1. [1]

    Agreement in epidemic infor- mation dissemination

    Mosab Ayiad, Amogh Katti, and Giuseppe Di Fatta. Agreement in epidemic infor- mation dissemination. InInternet and Distributed Computing Systems: 9th Interna- tional Conference, IDCS 2016, Wuhan, China, September 28-30, 2016, Proceedings 9, pages 95–106. Springer, 2016

    work page 2016

  2. [2]

    Agreement in epidemic data aggregation

    Mosab M Ayiad and Giuseppe Di Fatta. Agreement in epidemic data aggregation. In2017 IEEE 23rd International Conference on Parallel and Distributed Systems (ICPADS), pages 738–746. IEEE, 2017

    work page 2017

  3. [3]

    Sym- metric push-sum protocol for decentralised aggregation

    Francesco Blasa, Simone Cafiero, Giancarlo Fortino, Giuseppe Di Fatta, et al. Sym- metric push-sum protocol for decentralised aggregation. InProc. of the Int. l Conf. on Advances in P2P Systems, pages 27–32, 2011

    work page 2011

  4. [4]

    Frosty: Bringing strong liveness guarantees to the Snow family of consensus protocols

    AaronBuchwald, StephenButtolph, AndrewLewis-Pye, PatrickO’Grady, andKevin Sekniqi. Frosty: Bringing strong liveness guarantees to the snow family of consensus protocols.arXiv preprint arXiv:2404.14250, 2024

    work page Pith review arXiv 2024

  5. [5]

    Formal verification of multi- paxos for distributed consensus

    Saksham Chand, Yanhong A Liu, and Scott D Stoller. Formal verification of multi- paxos for distributed consensus. InInternational Symposium on Formal Methods, pages 119–136. Springer, 2016

    work page 2016

  6. [6]

    Blockchain Consensus Algorithms: A Survey

    Md Sadek Ferdous, Mohammad Jabed Morshed Chowdhury, Mohammad A Hoque, and Alan Colman. Blockchain consensus algorithms: A survey.arXiv preprint arXiv:2001.07091, 2020. 21 REFERENCES REFERENCES

    work page Pith review arXiv 2001

  7. [7]

    Evolution of blockchain consensus algorithms: a review on the latest milestones of blockchain consensus algorithms.Cybersecurity, 6(1):30, 2023

    Ziad Hussein, May A Salama, and Sahar A El-Rahman. Evolution of blockchain consensus algorithms: a review on the latest milestones of blockchain consensus algorithms.Cybersecurity, 6(1):30, 2023

    work page 2023

  8. [8]

    Proofs of work and bread pudding protocols

    Markus Jakobsson and Ari Juels. Proofs of work and bread pudding protocols. InSecure Information Networks: Communications and Multimedia Security IFIP TC6/TC11 Joint Working Conference on Communications and Multimedia Security (CMS’99) September 20–21, 1999, Leuven, Belgium, pages 258–272. Springer, 1999

    work page 1999

Show all 27 references
  1. [9]

    Gossip-based computation of ag- gregate information

    David Kempe, Alin Dobra, and Johannes Gehrke. Gossip-based computation of ag- gregate information. In44th Annual IEEE Symposium on Foundations of Computer Science, 2003. Proceedings., pages 482–491. IEEE, 2003

    2003

  2. [10]

    Ppcoin: Peer-to-peer crypto-currency with proof-of- stake.self-published paper, August, 19(1), 2012

    Sunny King and Scott Nadal. Ppcoin: Peer-to-peer crypto-currency with proof-of- stake.self-published paper, August, 19(1), 2012

    2012

  3. [11]

    Paxos made simple.ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001), pages 51–58, 2001

    Leslie Lamport. Paxos made simple.ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001), pages 51–58, 2001

    2001

  4. [12]

    Fast paxos.Distributed Computing, 19:79–103, 2006

    Leslie Lamport. Fast paxos.Distributed Computing, 19:79–103, 2006

    2006

  5. [13]

    Byzantizing paxos by refinement

    Leslie Lamport. Byzantizing paxos by refinement. InInternational symposium on distributed computing, pages 211–224. Springer, 2011

    2011

  6. [14]

    The byzantine generals prob- lem

    Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine generals prob- lem. InConcurrency: the works of leslie lamport, pages 203–226. 2019

    2019

  7. [15]

    Acomprehensivereviewofblockchainconsensus mechanisms.IEEE access, 9:43620–43652, 2021

    BaharehLashkariandPetrMusilek. Acomprehensivereviewofblockchainconsensus mechanisms.IEEE access, 9:43620–43652, 2021

    2021

  8. [16]

    Mstablechain: Towards multi-native stablecoins in evm-compatible blockchain for stable fee and mass adoption.arXiv preprint arXiv:2410.22100, 2024

    Mingzhe Li, Bo Gao, Kentaroh Toyoda, Yechao Yang, Juniarto Samsudin, Haibin Zhang, Sifei Lu, Tai Hou Tng, Kerching Choo, Andy Ting, et al. Mstablechain: Towards multi-native stablecoins in evm-compatible blockchain for stable fee and mass adoption.arXiv preprint arXiv:2410.221...

    arXiv

  9. [17]

    Kronos: A secure and generic sharding blockchain consensus with optimized overhead.Cryptology ePrint Archive, 2024

    Yizhong Liu, Andi Liu, Yuan Lu, Zhuocheng Pan, Yinuo Li, Jianwei Liu, Song Bian, and Mauro Conti. Kronos: A secure and generic sharding blockchain consensus with optimized overhead.Cryptology ePrint Archive, 2024

    2024

  10. [18]

    Bitcoin: A peer-to-peer electronic cash system.Satoshi Nakamoto, 2008

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system.Satoshi Nakamoto, 2008

    2008

  11. [19]

    NEO White Paper.https://docs.neo.org/v2/docs/zh-cn/basic/ whitepaper.html, 2022

    NEO. NEO White Paper.https://docs.neo.org/v2/docs/zh-cn/basic/ whitepaper.html, 2022. Accessed: 2022-03-04

    2022

  12. [20]

    In search of an understandable consensus algorithm

    Diego Ongaro and John Ousterhout. In search of an understandable consensus algorithm. In2014 USENIX annual technical conference (USENIX ATC 14), pages 305–319, 2014

    2014

  13. [21]

    Robust and efficient membership man- agement in large-scale dynamic networks.Future Generation Computer Systems, 75:85–93, 2017

    Pasu Poonpakdee and Giuseppe Di Fatta. Robust and efficient membership man- agement in large-scale dynamic networks.Future Generation Computer Systems, 75:85–93, 2017

    2017

  14. [22]

    Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies.Available [online].[Accessed: 4-12-2018], 2018

    Team Rocket. Snowflake to avalanche: A novel metastable consensus protocol family for cryptocurrencies.Available [online].[Accessed: 4-12-2018], 2018

    2018

  15. [23]

    Asurveyandtaxonomyofconsensusprotocolsforblockchains.Journal of Systems Architecture, 127:102503, 2022

    Arshdeep Singh, Gulshan Kumar, Rahul Saha, Mauro Conti, Mamoun Alazab, and RejiThomas. Asurveyandtaxonomyofconsensusprotocolsforblockchains.Journal of Systems Architecture, 127:102503, 2022

    2022

  16. [24]

    Securehigh-ratetransactionprocessinginbit- coin

    YonatanSompolinskyandAvivZohar. Securehigh-ratetransactionprocessinginbit- coin. InFinancial Cryptography and Data Security: 19th International Conference, FC 2015, San Juan, Puerto Rico, January 26-30, 2015, Revised Selected Papers 19, pages 507–527. Springer, 2015

    2015

  17. [25]

    Collachain: A bft collabo- rative middleware for decentralized applications.arXiv preprint arXiv:2203.12323, 2022

    Deepal Tennakoon, Yiding Hua, and Vincent Gramoli. Collachain: A bft collabo- rative middleware for decentralized applications.arXiv preprint arXiv:2203.12323, 2022. 23 REFERENCES REFERENCES

    2022 arXiv

  18. [26]

    Formalanalysisofaproof-of-stakeblockchain

    Wai Yan Maung Maung Thin, Naipeng Dong, Guangdong Bai, and Jin Song Dong. Formalanalysisofaproof-of-stakeblockchain. In2018 23rd International Conference on Engineering of Complex Computer Systems (ICECCS), pages 197–200. IEEE, 2018

    2018

  19. [27]

    Jabs: A blockchain simu- lator for researching consensus algorithms.IEEE Transactions on Network Science and Engineering, 2023

    Habib Yajam, Elnaz Ebadi, and Mohammad Ali Akhaee. Jabs: A blockchain simu- lator for researching consensus algorithms.IEEE Transactions on Network Science and Engineering, 2023. 24

    2023

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.