Pith. sign in

REVIEW 5 major objections 6 minor 65 references

Duet: Co-Optimizing P2P Message Propagation and Rotating-Leader Consensus

T0 review · 5 major / 6 minor · reviewed 2026-08-01 · deepseek-v4-flash

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

Pith's one-line read Because a blockchain is a replicated state machine, it can agree on its own network topology; Duet exploits this to route proposals along latency-aware trees and uses consensus votes as delivery acknowledgments, claiming up to 7.26× through

desk verdict Votes-as-ACK two-stage broadcast is a real idea and the 7.26× number is believable, but the liveness proof in §4.3 has a genuine hole and the eval needs more rigor. read the letter →

arxiv 2607.22209 v1 pith:4Y5VVHW6 submitted 2026-07-24 cs.DC

Yifeng Ye , Rongji Huang , Gerui Wang , Mingchao Wan , Yuxing Duan , Jingjing Zhang , Shengyun Liu This is my paper · ORCID
classification cs.DC
keywords P2Poverlayrotating-leaderconsensusByzantinefaulttoleranceTenderminttree-basedbroadcastgossipfallbacktopology-awarepipelined
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

Duet sets out to show that the wall between the consensus layer and the P2P network is unnecessary. Because a blockchain is a replicated state machine, it can use its own consensus to record who is connected to whom and how fast, and then use that ground truth to fix two blockers in rotating-leader protocols: how quickly proposals arrive and where they travel. The paper's proposal-dissemination mechanism is two-stage: each proposer pushes its block along a per-proposer, latency-aware tree, and only when expected vote acknowledgments fail to arrive does a node fall back to gossip retransmission, targeted only at silent peers. This keeps normal-case traffic near tree cost instead of mesh cost, keeps the pipelined protocol full, and the authors report a peak throughput gain of 7.26× over gossip at 300 nodes across 10 AWS regions. The significance, if correct, is that consensus and networking can be co-optimized rather than treated as opaque layers.

What carries the argument

The load-bearing mechanism is the vote-as-ACK handshake between the two stages of proposal dissemination. A dissemination tree per proposer is built greedily from the on-chain weighted graph using edge time = delay(v) + |m|·deg(u)/B(u,v), with B estimated from RTT by a TCP-inspired window model; a proposer ring is built by a greedy nearest-neighbor TSP on shortest-path distances. The consensus prevote—already sent for the proposal—doubles as proof of receipt, so once the tree-phase timer expires a node retransmits the proposal only to peers from which no prevote has been observed, then falls back to the existing gossip mesh. The network reconfiguration abstraction lets the system install and

What would settle it

Instrument a 100-node, 10-region run and count, per round, the number of proposal retransmissions triggered after the tree timer. If with a 3 s timer the average pushes per node-height already exceeds the ~0.045 reported and throughput drops toward the gossip baseline before any node crashes, then the claimed normal-case tree delivery does not hold at the assumed δ; conversely, setting the timer to 500 ms should by the paper's own data produce ~1.8 pushes per node-height and roughly 12k tps, a specific quantitative prediction a reader could check.

Watch

Extended reading notes

Core claim

The central discovery is that the votes a consensus protocol must send anyway can double as delivery acknowledgments for best-effort broadcast, which turns an efficient but unreliable dissemination tree into a reliable primitive. Concretely, Duet constructs a proposer ring with a greedy nearest-neighbor heuristic and, for every proposer, a spanning tree whose edges are scored by propagation delay plus a transmission-delay term that depends on fanout and RTT-estimated bandwidth, with a tiebreak favoring upcoming proposers. A proposal is first sent only along that tree; every node that receives it casts its prevote, and the proposer and other relaying nodes treat missing prevotes as evidence o

Load-bearing premise

The liveness argument stands on the assumption that the tree-phase delivery time has a known bound δ that holds after stabilization—including through the modified pipeline and the added tree phase—so that a proposal reaches enough correct nodes within 2δ to trigger retransmission, and the gossip fallback completes within Δ; if the real tree latency exceeds δ (congested relay, overloaded node, or a topology record influenced by a faulty sender), the retransmission stage would

Editorial extensions

If this is right

  • If Duet is correct, rotating-leader BFT protocols can shed most redundant WAN proposal traffic in the normal case without giving up reliable delivery, because failures are repaired on demand rather than pre-emptively.
  • The experiments predict that greedy proposer ordering pays off only when it is coordinated with tree construction: alone it changes throughput by at most ~4% for gossip or a K-ary tree, but with Duet's trees it contributes a 3.06× gain at N=100.
  • The throughput advantage grows with scale (7.26× at 300 nodes vs 1.18× at 10 nodes), suggesting the mechanism targets the regime in which path locality and pipelining degrade most for unstructured dissemination.
  • The tree-phase timer is a first-class deployment parameter: in the fault-free 100-node test, shrinking it from 3 s to 2 s already costs ~22% throughput, so deployments must calibrate it to the measured tail of tree delivery.
  • Safety is inherited unchanged from the underlying consensus protocol because only message propagation, not quorum rules, is modified; liveness depends on the timer configuration, which the paper ties to the network bound Δ.

Reading between the lines

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

  • An implication left implicit is that the vote-as-ACK idea transfers naturally to DAG-based and multi-leader protocols, where multiple proposals are in flight and redundant broadcast is the main bandwidth cost; tree-routing there could yield even larger absolute savings.
  • A testable extension: if latency records can be distorted by a Byzantine actor for a few nodes, the tree-selection algorithm might be steered to isolate a target region, forcing the gossip fallback every round; the paper's limited-visibility study (20 exposed links) only partially quantifies this, so it could be probed with adversarial RTT edits.
  • The bandwidth model predicts the gain shrinks for small blocks: when |m| is small, transmission delay is negligible and the edge cost is just propagation delay, so the residual advantage over gossip comes mainly from avoiding duplicate transmissions rather than from path optimization—an experiment with 100 KB instead of 10 MB blocks would test this.
  • The authors' own crash results imply a sharper boundary: at 10% random node crashes, 43% of trees fail to reach quorum, so Duet's advantage may be concentrated in the fault-free normal case; a Markov model of how often a round needs the retransmission stage would let operators trade tree-timer length against worst-case recovery latency.
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

5 major / 6 minor

Summary. Duet proposes a cross-layer co-design for rotating-leader consensus (a pipelined Tendermint variant) and P2P dissemination on libp2p. Network topology and pairwise latencies are assumed to be recorded in a consensus-maintained ledger (the NR primitive); a greedy nearest-neighbor algorithm arranges proposers into a low-latency ring; proposal dissemination uses per-proposer, multi-factor-aware trees in a fast tree phase, with consensus votes as acknowledgments and a gossip retransmission stage triggered by a tree-phase timer when votes are missing. The authors implement Duet on Tendermint/libp2p and evaluate it on Amazon EC2 across 10 regions with up to 300 nodes, reporting peak throughput up to 7.26x over gossip-based dissemination on the same topology, together with an ablation study, timer sensitivity, crash and leader-failure experiments, and an Ethereum-like heterogeneous placement.

Significance. The cross-layer idea is well motivated and the reported gains are large: at N=300, 20,504/2,821 is about 7.27x, consistent with the abstract. The evaluation is fair in an important respect: Duet and the two baselines share the same topology, vote dissemination, buffering, and pipelining logic, and the ablation in Figure 8 cleanly isolates the proposer-ordering and tree-dissemination effects. The paper also explicitly acknowledges limitations, including the 33% crash regime where Duet falls below Gossip (Section 5.6) and the topology-visibility tradeoff (Section 4.3). Code is released. However, the liveness argument in Section 4.3 is not a sound proof as written: it relies on a proposer-side gossip retransmission that is absent from the pseudocode, contains a zero-slack timing chain, and states an invariant that the algorithm itself violates. Since liveness preservation is a central advertised property, this must be repaired before the paper can be recommended for acceptance.

major comments (5)
  1. [4.3 / Algorithm 3 (Appendix A)] The liveness proof assumes 'node p gossips its proposal before time t+Delta+4delta', but the pseudocode never has the current proposer perform such a gossip. In Algorithm 3, startRound calls Tree-broadcast only for the proposer; the tree-phase timer OnTimeoutDiss is scheduled only by non-proposers. The Gossip calls in Algorithm 2 occur when a node receives a proposal while in the propose step, or in OnTimeoutDiss when step != best, neither of which is triggered for the current proposer. Thus the retransmission on which the proof relies is not specified. In addition, the timing has zero slack: with tmr_tree=2delta and tmr_propose=2Delta+2delta, node i's propose timer expires at t+2Delta+4delta, which is exactly the arrival time of a gossip message sent at t+Delta+4delta under the Delta delivery bound. Any jitter or clock skew produces a nil prevote. Add a proposer-side retransmission and
  2. [4.3 Correctness argument] The claimed target property -- 'every proposal issued by a correct proposer is prevoted by all correct nodes' -- is false for the algorithm as written. In Algorithm 2, a node that is locked on a different value does not prevote a valid proposal for another value; it broadcasts prevote nil (lines 2-9). Tendermint liveness needs only 2f+1 prevotes for a value, not all correct nodes. The proof should instead show timely receipt by enough correct nodes (and, where relevant, the ability to unlock via newer-round prevotes). As written, the argument establishes a statement the code does not satisfy, so it cannot support the liveness conclusion.
  3. [4.3 Timing assumptions] The bound 'node p should enter round r before time t+Delta+2delta' is asserted, not derived. Invariant 1 is stated for vanilla Tendermint in Section 2.3, but Duet adds a tree phase and lengthens propose timers for reorg resilience; it is not immediate that the invariant survives in the modified pipeline, and no induction over rounds/heights is provided. The brief explanation that the previous proposer may need an extra 2delta to switch to retransmission is a sketch, not a proof. A complete liveness argument must cover faulty tree relays and show, after GST, that a correct proposer's proposal reaches the required correct nodes before their propose timers expire.
  4. [5.2 / Figures 6-7] The evaluation contains no error bars, repeated-run counts, or variance information; the headline 7.26x is a point measurement. Several numbers in the text disagree with the figures: Section 5.2 says K-ary N=50 reaches 5.36k tps and Gossip N=50 reaches 3.40k tps, while Figure 7 shows 5,473 and 3,762; the text gives Duet N=10 as 14.07k tps while Figure 7 shows 15,160. Please report the number of runs and run duration, add variance, reconcile all reported values, and state clearly which data points are peak-saturation values and which are from a fixed batch size.
  5. [3.1 / 5.1] The Network Reconfiguration (NR) primitive and the on-chain network ledger chi are a core part of the proposed co-design, but the evaluation never exercises them. The experiments start from a predetermined topology G with known RTTs; there is no measurement of the cost of recording or updating chi (ledger size, reconfiguration latency, consensus overhead), nor any treatment of Byzantine nodes submitting false latency or topology data. Without this, the experiments support static topology-aware dissemination and proposer ordering, but not the full 'recorded in a trusted and coordinated manner' loop claimed in the introduction.
minor comments (6)
  1. [Figure 5] The caption contains unresolved 'Figure ??' references for the normal and crash cases; please fix.
  2. [Appendix A / Algorithms] Algorithm 2 uses '2Delta'' in comments without defining Delta', while Algorithm 3 uses 2Delta+2delta. Use one consistent notation. Also, the intended grey highlighting of Duet modifications is not visible in the text; please mark changed lines explicitly.
  3. [5.1 Baselines] The K-ary tree baseline is described as the structure used by Kauri, but Kauri includes adaptive reconfiguration and pipelined aggregation. The baseline is a simplified balanced tree; please state that it is Kauri-inspired rather than Kauri itself.
  4. [4.2] The 10% tie-break threshold is not ablated or justified; please state that it is a heuristic and discuss sensitivity, or add an experiment.
  5. [5.2] The sentence 'Duet follows the opposite trend from N=10 to N=100' is misleading because Figure 7 shows throughput declining from N=100 to N=300; qualify the trend.
  6. [General] Minor terminology/typography issues: 'precommit' and 'pre-commit' are used inconsistently, and 'treephase timer' appears as 'tree-phase timer' and 'treephase' in different places. A final proofread would help.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: throughput result is measured; liveness proof gap is a correctness risk, not a reduction to inputs.

full rationale

The paper's headline claim is an empirical comparison, not a fitted prediction: Section 5.1 fixes the same topology for Duet, Gossip, and K-ary tree and varies only proposal dissemination, so the 7.26x throughput figure is a measured outcome rather than a quantity derived from the parameters that produced it. The proposer-ring and tree-construction heuristics in Sections 4.1 and 4.2 are design choices whose benefits are then evaluated experimentally, and the bandwidth model B(u,v)=min(Bmax, kappa/RTT) is an external TCP-inspired approximation, not a self-citation or an ansatz disguised as a theorem. The liveness argument in Section 4.3 is the only load-bearing formal claim, and it is not circular in the input-output sense: it explicitly conditions on Invariant 1 and on timer bounds delta and Delta, then derives a timing equation. However, it does contain a serious correctness gap that should be flagged as a limitation, not as circularity: the calculation places proposal arrival exactly at propose-timer expiry with zero slack, and the proof assumes the proposer gossips its proposal before t+Delta+4delta, while Algorithm 3 schedules OnTimeoutDiss only for non-proposers and the proposer never schedules a gossip fallback. That is an omitted or unsupported proof step, not a reduction of the conclusion to its own assumptions. The same-group reference [30] (Chitu) overlaps thematically with the two-stage fallback idea, but it is not cited as the basis for Duet's design and is not load-bearing; the pipelined Tendermint variant is attributed to the authors' enterprise system but is independently supported by the existing pipelined HotStuff reference [22]. No self-definitional equation, fitted-input-as-prediction, or uniqueness-imported-from-authors step appears in the derivation chain. Hence no significant circularity.

Assumptions & free parameters 9 free parameters · 6 assumptions · 2 invented entities

The central claim is empirical, so the axiom ledger captures what the measurement setup postulates: a partially synchronous model with N≥3f+1, the inherited Tendermint invariance, a trusted consensus-recorded latency ledger, and a heuristic bandwidth model whose constants (κ=20000, B_max=800 Mb/s) and timers (2δ=3s) are hand-set. The free parameters are numerous and the paper itself shows throughput is highly sensitive to the tree-phase timer (§5.4). No new physical entities are introduced; the NR abstraction and the two-stage broadcast are protocol-level inventions with no independent falsifiable evidence outside the paper's own testbed.

free parameters (9)
  • κ (bandwidth-model constant) = 20000
    In B(u,v)=min(B_max, κ/RTT) (§4.2), hand-set to 20000 without justification or sensitivity analysis; directly shapes the dissemination trees and therefore the measured throughput.
  • B_max (bandwidth cap) = 800 Mb/s
    Cap on modeled link bandwidth set in §5.1; no sensitivity analysis; affects tree construction and the headroom for concurrent transmissions.
  • |m| (payload/block size) = 10 MB
    Set in §5.1 as the block size; used in the transmission-delay term of the tree-selection formula (§4.2) and in all experiments; deployment-specific.
  • tree-phase timer (2δ) = 3 s (default in §5.6)
    Critical deployment-specific timer: §5.4 shows throughput varies from 21.2k to 12.0k tps as it is set from 5s to 500ms; the paper itself flags it as 'critical ... must be carefully tuned.'
  • Δ (partially-synchronous bound) = not stated
    Used in the liveness argument (§4.3) to set t_propose=2Δ+2δ, but no numerical value is given in the evaluation; δ is also unspecified relative to actual AWS RTTs.
  • average node degree d = 20 (N=50), 40 (N=100/300); fully connected at N=10
    The test topology in §5.1 is built with these degrees; no sensitivity analysis is provided, and the tree/ring quality depends on the sparsity.
  • K (K-ary baseline branching factor) = 3 (N=10), 5 (N≥50)
    Chosen for the baseline tree in §5.1; the K-ary baseline does not use latency awareness, so the choice bounds how strong the comparison is.
  • 10% tie-break threshold = 10%
    In §4.2, if estimated delays differ by less than 10%, the tree builder prioritizes the node closer in the proposer sequence; this threshold is hand-set.
  • GossipSub mesh degree = 6
    Used for all vote dissemination and for the Gossip baseline's proposal dissemination (§5.1); the choice affects the baseline's redundancy and Duet's own vote traffic.
assumptions (6)
  • domain assumption Partially synchronous model with N≥3f+1 (§2.1)
    Standard Dwork-Lynch-Stockmeyer model; all liveness claims depend on the existence of Δ after GST.
  • domain assumption Invariant 1: after GST, all correct nodes advance to the next step within Δ (§2.3)
    Inherited from vanilla Tendermint; the liveness argument in §4.3 uses this invariant without re-proving it for the modified timers and the added tree phase.
  • ad hoc to paper Trusted, consensus-recorded network ledger (NR abstraction, §3.1)
    Assumes the blockchain can agree on and install accurate topology and latency data χ=(vid,Π,Λ); the evaluation uses static, externally-assigned region-to-region RTTs rather than measured, consensus-verified per-node latencies.
  • ad hoc to paper Heuristic 1: the faster a proposer receives the preceding proposal, the sooner it can generate its own proposal (§3.2)
    The TSP/greedy-ring optimization is motivated by this heuristic, which is not derived or proven; the ablation (§5.3) empirically supports it, but only within the specific pipelined setup.
  • standard math Mathis TCP throughput model: single-flow throughput ∝ 1/RTT (§4.2)
    Cited from [39] to justify B(u,v)=κ/RTT; a standard approximation, but its constants are not transferable without tuning.
  • domain assumption Safety is preserved because quorum intersection is unchanged by the dissemination layer (§4.3)
    Reasonable: proposals are not votes, and vote dissemination uses the same gossip as before; however, this is asserted informally, not proven.
invented entities (2)
  • Network Reconfiguration (NR) primitive / on-chain network ledger χ=(vid, Π, Λ)
    purpose: To record network topologies and latencies via consensus so every node holds identical network information for tree and ring construction (§3.1).
    The NR abstraction is a protocol-level construct implemented only within Duet; the evaluation supplies G externally rather than exercising the NR itself, so there is no falsifiable handle outside the paper.
  • Two-stage broadcast with a dedicated tree phase and consensus-vote acknowledgments
    purpose: To make proposal dissemination efficient in the normal case (tree) and reliable in the fallback case (gossip triggered by missing prevotes) (§3.3, §4.3).
    This is the paper's core protocol mechanism; it is validated by the prototype evaluation but has no externally falsifiable prediction beyond its own testbed measurements.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Duet: Co-Optimizing P2P Message Propagation and Rotating-Leader Consensus." pith.science (2026). https://pith.science/paper/4Y5VVHW6

@misc{pith2026260722209,
  author       = {Pith},
  title        = {Pith review of: Duet: Co-Optimizing P2P Message Propagation and Rotating-Leader Consensus},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4Y5VVHW6}},
  note         = {Machine review of arXiv:2607.22209}
}
abstract

In blockchain systems, peer-to-peer (P2P) overlay networks play a crucial role in providing reliable, scalable and efficient message-delivery services to upper layers. However, the consensus layer and the underlying P2P network remain mutually opaque in existing blockchains, waiving the opportunity for further improvement. In contrast to other P2P applications, blockchain can naturally be abstracted as a state machine. We therefore leverage this abstraction to record network topologies and latencies in a trusted and coordinated manner. With this support, we propose three improvements to rotating-leader consensus protocols and their underlying P2P networks: (1) accelerating leader rotation; (2) introducing a reliable-broadcast paradigm that employs tree-based dissemination in the normal case and falls back to gossip only when necessary; and (3) constructing latency-aware dissemination trees. We integrate the above ideas into Tendermint and libp2p, and conduct empirical evaluation on Amazon EC2 platform using up to 300 nodes distributed across 10 regions. The results demonstrate that, compared with gossip-based dissemination over the same topology, our prototype improves peak throughput by up to $7.26\times$.

Figures

Figures reproduced from arXiv: 2607.22209 by the authors.

Figure 1
Figure 1. The message pattern of Tendermint (𝑁 = 3𝑓 + 1). using only a three-phase message pattern, even across pro￾poser rotations triggered by faulty or malicious proposers. Tendermint also proactively rotates proposers across block heights to ensure a fair distribution of proposal opportuni￾ties. Within each height, Tendermint proceeds through re￾peated rounds, with each containing propose, prevote, and precommit phases. T… view at source ↗
Figure 2
Figure 2. The procedures for network evolution. start any timer at height ℎ only after committing a proposal at height ℎ − 1. 3 Co-design ideas 3.1 Ledgers for networking By recording network topologies and latencies on-chain, every node in the system keeps the current network infor￾mation locally; for every membership change, the system is required to reach a consensus on it to synchronize the new network information. Simila… view at source ↗
Figure 3
Figure 3. Illustration of proposal dissemination in tree-based and gossip-based Communication Networks. Through gos￾sip, each node propagates messages to three neighbors. As￾sume 𝑓 = 5 and there are a total of 𝑁 = 3𝑓 + 1 = 16 nodes. Without redundant dissemination, if node 𝑝 crashes, its de￾scendants in the tree can no longer receive the proposal. As they constitute more than 𝑓 nodes, the upper consensus layer can no longer g… view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: Examples for Duet tree-based dissemination (𝑛 = 7). In Figure ??, the propose phase is skipped as all correct nodes receive proposal 𝑣 during the tree phase. In Figure ??, nodes 2 and 4 crash; consequently, nodes 5 and 6 cannot receive proposal 𝑣 during the tree phase.…
Figure 6
Figure 6. Figure 6: Performance as the system scales from 𝑁=10 to 𝑁=100. 10 50 100 300 Number of nodes (N) 0 10k 20k Throughput (tps) 15,160 17,081 22,028 20,504 11,936 5,473 4,943 4,212 6,609 3,762 3,442 2,821 Duet K-ary tree Gossip [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Peak throughput as 𝑁 scales from 10 to 300. only 3.40k tps with a corresponding latency of 1531 ms. For both baselines, the additional drop from 𝑁 = 50 to 𝑁 = 100 is smaller because the pipeline is already partially under￾utilized at 𝑁 = 50. Larger scale mainly worsens…
Figure 8
Figure 8. Figure 8: Ablation Study of Dissemination and Proposer Ordering (𝑁=100, 10-region WAN, batch size 10k). 5s 3s 2s 1s 500ms tree-phase timer 0 5k 10k 15k 20k 25k Throughput (tps) 21,189 21,090 16,695 13,592 12,016 0.0 0.5 1.0 1.5 2.0 Pushes per node-height 0.004 0.045 0.574 1.208 …
Figure 10
Figure 10. Figure 10: Throughput–latency under the Ethereum-like de￾ployment (𝑁=100). N. Virginia Ohio N. California Ireland London Frankfurt Tokyo Singapore Sydney 0 1,000 2,000 3,000 4,000 5,000 6,000 7,000 Latency (ms) Duet Gossip K-ary tree [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 12
Figure 12. Figure 12: Throughput under crash faults (no leader/proposer crashes). 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Tree dissemination coverage 0.00 0.25 0.50 0.75 1.00 Cumulative fraction of trees 2/3 quorum 11% below quorum 43% below quorum 100% below quorum 5% crash 10% crash …
Figure 14
Figure 14. Figure 14: Performance under leader faults. both failure types, delaying retransmission in one and ex￾tending the failover window in the other; following §5.4, we set it to 3 s to sustain normal-case throughput, while deploy￾ments that prioritize faster recovery can choose a sma…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

65 extracted references · 3 canonical work pages

  1. [1]

    [n. d.]. AWS Latency Monitoring.https://www.cloudping.co/. Ac- cessed: 2026-05-28

    2026

  2. [2]

    [n. d.]. Ethernodes: Ethereum Mainnet Node Explorer.https://www. ethernodes.org/. Accessed: 2026-05-28

    2026

  3. [3]

    [n. d.]. Gossip data dissemination protocol.https://hyperledger-fabric. readthedocs.io/en/release-1.2/gossip.html#gossip-protocol. Accessed: 2026-05-28

    2026

  4. [4]

    [n. d.]. A modular p2p network stack.https://libp2p.io/. Accessed: 2026-05-28

    2026

  5. [5]

    Filecoin: A Decentralized Storage Network.https://filecoin.io/ filecoin.pdf

    2017. Filecoin: A Decentralized Storage Network.https://filecoin.io/ filecoin.pdf

    2017

  6. [6]

    Ittai Abraham, Kartik Nayak, and Nibesh Shrestha. 2021. Optimal Good-case Latency for Rotating Leader Synchronous BFT. Cryptology ePrint Archive, Paper 2021/1138. doi:10.4230/LIPIcs.OPODIS.2021.27

    work page doi:10.4230/lipics.opodis.2021.27 2021

  7. [7]

    Ailidani Ailijiang, Aleksey Charapko, Murat Demirbas, and Tevfik Kosar. 2020. WPaxos: Wide Area Network Flexible Consensus.IEEE Trans. Parallel Distrib. Syst.31, 1 (Jan. 2020), 211–223. doi:10.1109/ TPDS.2019.2929793

    arXiv 2020

  8. [8]

    Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstantinos Christidis, Angelo De Caro, David Enyeart, Christo- pher Ferris, Gennady Laventman, Yacov Manevich, Srinivasan Mu- ralidharan, Chet Murthy, Binh Nguyen, Manish Sethi, Gari Singh, Keith Smith, Alessandro Sorniotti, Chrysoula Stathakopoulou, Marko Vukolić, Sharon Weed Cocco, and J...

    arXiv 2018

Show all 65 references
  1. [9]

    Vijeth Aradhya, Seth Gilbert, and Aquinas Hobor. 2025. Robust over- lays meet blockchains: On handling high churn and catastrophic fail- ures.Theoretical Computer Science1051 (2025), 115415. doi:10.1016/j. tcs.2025.115415

    2025

  2. [10]

    Leemon Baird. 2016. The swirlds hashgraph consensus algorithm: Fair, fast, byzantine fault tolerance.Swirlds Tech Reports SWIRLDS-TR-2016- 01, Tech. Rep34 (2016), 9–11

    2016

  3. [11]

    Ken Birman. 2007. The promise, and limitations, of gossip protocols. SIGOPS Oper. Syst. Rev.41, 5 (Oct. 2007), 8–13. doi:10.1145/1317379. 1317382

    2007 doi

  4. [12]

    Ethan Buchman, Jae Kwon, and Zarko Milosevic. 2018. The latest gos- sip on BFT consensus.CoRRabs/1807.04938 (2018). arXiv:1807.04938

    2018 arXiv

  5. [13]

    Vitalik Buterin et al . 2014. A next-generation smart contract and decentralized application platform.white paper3, 37 (2014)

    2014

  6. [14]

    Vitalik Buterin, Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Danny Ryan, Juhyeok Sin, Ying Wang, and Yan X. Zhang

  7. [15]

    2011.In- troduction to reliable and secure distributed programming

    Christian Cachin, Rachid Guerraoui, and Luís Rodrigues. 2011.In- troduction to reliable and secure distributed programming. Springer Science & Business Media

    2011

  8. [16]

    Christian Cachin, Simon Schubert, and Marko Vukolić. 2016. Non-determinism in Byzantine Fault-Tolerant Replication. arXiv:1603.07351 [cs.DC]https://arxiv.org/abs/1603.07351

    2016 arXiv

  9. [17]

    Bengt Carlsson and Rune Gustavsson. 2001. The Rise and Fall of Napster - An Evolutionary Approach. InActive Media Technology, Jiming Liu, Pong C. Yuen, Chun-hung Li, Joseph Ng, and Toru Ishida (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 347–354

    2001

  10. [18]

    Miguel Castro and Barbara Liskov. 1999. Practical Byzantine fault tolerance. InProceedings of the Third Symposium on Operating Systems Design and Implementation(New Orleans, Louisiana, USA)(OSDI ’99). USENIX Association, USA, 173–186

    1999

  11. [19]

    Scott A Crosby and Dan S Wallach. 2007. An analysis of bittorrent’s two kademlia-based dhts. (2007)

    2007

  12. [20]

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexan- der Spiegelman. 2022. Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Consensus. InProceedings of the Seventeenth Euro- pean Conference on Computer Systems(Rennes, France)(EuroSys ’22). Association f...

    2022

  13. [21]

    Huynh Tu Dang, Pietro Bressana, Han Wang, Ki Suh Lee, Noa Zil- berman, Hakim Weatherspoon, Marco Canini, Fernando Pedone, and Robert Soulé. 2020. P4xos: Consensus as a Network Service.IEEE/ACM Trans. Netw.28, 4 (aug 2020), 1726–1738. doi:10.1109/TNET.2020. 2992106

    2020 doi

  14. [22]

    Isaac Doidge, Raghavendra Ramesh, Nibesh Shrestha, and Joshua To- bkin. 2024. Moonshot: Optimizing Block Period and Commit Latency in Chain-Based Rotating Leader BFT. In2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 470–482. doi:1...

    2024

  15. [23]

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. 1988. Consensus in the Presence of Partial Synchrony.J. ACM35, 2 (April 1988), 288–323. doi:10.1145/42282.42283

    1988

  16. [24]

    Michael Feldmann, Christian Scheideler, and Stefan Schmid. 2020. Survey on Algorithms for Self-Stabilizing Overlay Networks.ACM Comput. Surv.53, 4, Article 74 (jul 2020), 24 pages. doi:10.1145/3397190

    2020 doi

  17. [25]

    Fischer, Nancy A

    Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. 1985. Impossibility of distributed consensus with one faulty process.J. ACM 32, 2 (apr 1985), 374–382. doi:10.1145/3149.214121

    1985

  18. [26]

    Golan Gueta, I

    G. Golan Gueta, I. Abraham, S. Grossman, D. Malkhi, B. Pinkas, M. Reiter, D. Seredinschi, O. Tamir, and A. Tomescu. 2019. SBFT: A Scalable and Decentralized Trust Infrastructure. In2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 568–580

    2019

  19. [27]

    Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg

  20. [28]

    Karla L Hoffman, Manfred Padberg, Giovanni Rinaldi, et al. 2013. Trav- eling salesman problem.Encyclopedia of operations research and man- agement science1 (2013), 1573–1578

    2013

  21. [29]

    Guanzhou Hu, Yiwei Chen, Andrea Arpaci-Dusseau, and Remzi Arpaci- Dusseau. 2025. Crossword: Adaptive Consensus for Dynamic Data- Heavy Workloads. arXiv:2509.07157 [cs.DC]https://arxiv.org/abs/ 2509.07157

    2025 arXiv

  22. [30]

    Rongji Huang, Xiangzhe Wang, Xiaofeng Yan, Lei Fan, Guangtao Xue, and Shengyun Liu. 2025. Chitu: Avoiding Unnecessary Fallback in Byzantine Consensus. In2025 USENIX Annual Technical Conference (USENIX ATC 25). USENIX Association, Boston, MA, 923–942.https: //www.usenix.org/con...

    2025

  23. [31]

    Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, Ismail Khoffi, Linus Gasser, and Bryan Ford. 2016. Enhancing bitcoin security and performance with strong consistency via collective signing. In Proceedings of the 25th USENIX Conference on Security Symposium (Aust...

    2016

  24. [32]

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. 2010. Zyzzyva: Speculative Byzantine Fault Tolerance. ACM Trans. Comput. Syst.27, 4, Article 7 (jan 2010), 39 pages

    2010

  25. [33]

    Jae Kwon and Ethan Buchman. 2019. Cosmos whitepaper.A Netw. Distrib. Ledgers27, 1-32 (2019), 24

    2019

  26. [34]

    Sharma, Adriana Szekeres, and Dan R

    Jialin Li, Ellis Michael, Naveen Kr. Sharma, Adriana Szekeres, and Dan R. K. Ports. 2016. Just say no to paxos overhead: replacing consensus with network ordering. InProceedings of the 12th USENIX Conference on Operating Systems Design and Implementation(Savannah, GA, USA) (OS...

    2016

  27. [35]

    Shengyun Liu, Wenbo Xu, Chen Shan, Xiaofeng Yan, Tianjing Xu, Bo Wang, Lei Fan, Fuxi Deng, Ying Yan, and Hui Zhang. 2023. Flexible Advancement in Asynchronous BFT Consensus. InProceedings of the 29th Symposium on Operating Systems Principles(Koblenz, Germany) (SOSP ’23). Assoc...

    2023

  28. [36]

    Dmitri Loguinov, Anuj Kumar, Vivek Rai, and Sai Ganesh. 2003. Graph- Theoretic Analysis of Structured Peer-to-Peer Systems: Routing Dis- tances and Fault Resilience. InProceedings of the 2003 Conference on Applications, Technologies, Architectures, and Protocols for Com- puter...

    2003

  29. [37]

    Dahlia Malkhi, Moni Naor, and David Ratajczak. 2002. Viceroy: a scalable and dynamic emulation of the butterfly. InProceedings of the Twenty-First Annual Symposium on Principles of Distributed Comput- ing(Monterey, California)(PODC ’02). Association for Computing Machinery, Ne...

    2002

  30. [38]

    Parisa Jalili Marandi, Marco Primi, Nicolas Schiper, and Fernando Pe- done. 2010. Ring Paxos: A high-throughput atomic broadcast protocol. In2010 IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). 527–536. doi:10.1109/DSN.2010.5544272

    2010

  31. [39]

    Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, and Teunis Ott

  32. [40]

    Petar Maymounkov and David Mazières. 2002. Kademlia: A Peer-to- Peer Information System Based on the XOR Metric. InRevised Papers from the First International Workshop on Peer-to-Peer Systems (IPTPS ’01). Springer-Verlag, Berlin, Heidelberg, 53–65

    2002

  33. [41]

    Shuai Mu, Kang Chen, Yongwei Wu, and Weimin Zheng. 2014. When paxos meets erasure code: reduce network and storage cost in state machine replication. InProceedings of the 23rd International Symposium on High-Performance Parallel and Distributed Computing(Vancouver, BC, Canada)...

    2014

  34. [42]

    Satoshi Nakamoto. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System.https://bitcoin.org/bitcoin.pdf

    2008

  35. [43]

    Gleb Naumenko, Gregory Maxwell, Pieter Wuille, Alexandra Fedorova, and Ivan Beschastnikh. 2019. Erlay: Efficient Transaction Relay for Bitcoin. InProceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security(London, United Kingdom)(CCS ’19). Association...

    2019

  36. [44]

    Ray Neiheiser, Miguel Matos, and Luís Rodrigues. 2021. Kauri: Scal- able BFT Consensus with Pipelined Tree-Based Dissemination and Aggregation. InProceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. Association for Computing Machinery, New York, NY, USA, 35–48

    2021

  37. [45]

    Pinar Ozisik, Gavin Andresen, Brian N

    A. Pinar Ozisik, Gavin Andresen, Brian N. Levine, Darren Tapp, George Bissias, and Sunny Katkuri. 2019. Graphene: efficient interactive set reconciliation applied to blockchain propagation. InProceedings of the ACM Special Interest Group on Data Communication(Beijing, China) (...

    2019

  38. [46]

    Daniel Qian, Xiyu Hao, Jinkun Geng, Yuncheng Yao, Aurojit Panda, Jinyang Li, and Anirudh Sivaraman. 2026. Revisiting Speculative Leaderless Protocols for Low-Latency BFT Replication. arXiv:2601.03390 [cs.DC]https://arxiv.org/abs/2601.03390

    2026 arXiv

  39. [47]

    Haoran Qiu, Tao Ji, Shixiong Zhao, Xusheng Chen, Ji Qi, Heming Cui, and Sen Wang. 2023. A Geography-Based P2P Overlay Network for Fast and Robust Blockchain Systems.IEEE Transactions on Services Computing16, 3 (2023), 1572–1588. doi:10.1109/TSC.2022.3189667

    2023

  40. [48]

    Venugopalan Ramasubramanian, Dahlia Malkhi, Fabian Kuhn, Ma- hesh Balakrishnan, Archit Gupta, and Aditya Akella. 2009. On the treeness of internet latency and bandwidth. InProceedings of the Eleventh International Joint Conference on Measurement and Model- ing of Computer Syst...

    2009

  41. [50]

    M. Ripeanu. 2001. Peer-to-peer architecture case study: Gnutella network. InProceedings First International Conference on Peer-to-Peer Computing. 99–100. doi:10.1109/P2P.2001.990433

    2001

  42. [51]

    Team Rocket, Maofan Yin, Kevin Sekniqi, Robbert van Renesse, and Emin Gün Sirer. 2019. Scalable and probabilistic leaderless BFT con- sensus through metastability.arXiv preprint arXiv:1906.08936(2019). 14

    2019 arXiv

  43. [52]

    Antony I. T. Rowstron and Peter Druschel. 2001. Pastry: Scalable, Decentralized Object Location, and Routing for Large-Scale Peer-to- Peer Systems. InProceedings of the IFIP/ACM International Conference on Distributed Systems Platforms Heidelberg (Middleware ’01). Springer- Ve...

    2001

  44. [53]

    Schneider

    Fred B. Schneider. 1990. Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial.ACM Comput. Surv.22, 4 (Dec. 1990), 299–319. doi:10.1145/98163.98167

    1990

  45. [54]

    Ruisheng Shi, Yuxuan Liang, Zijun Guo, Qin Wang, Lina Lan, Chenfeng Wang, and Zhuoyi Zheng. 2026. Eclipse Attacks on Ethereum’s Peer- to-Peer Network. InProceedings of the ACM Web Conference 2026. 2740–2751

    2026

  46. [55]

    Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris-Kogias. 2022. Bullshark: DAG BFT Protocols Made Practi- cal. InProceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security(Los Angeles, CA, USA)(CCS ’22). As- sociation for C...

    2022

  47. [56]

    Chrysoula Stathakopoulou, Matej Pavlovic, and Marko Vukolić. 2022. State Machine Replication Scalability Made Simple. InProceedings of the Seventeenth European Conference on Computer Systems(Rennes, France)(EuroSys ’22). Association for Computing Machinery, New York, NY, USA, ...

    2022

  48. [57]

    Frans Kaashoek, and Hari Balakrishnan

    Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. 2001. Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications. InProceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Commu...

    2001

  49. [58]

    Nik Sultana, Salvator Galea, David Greaves, Marcin Wojcik, Jonny Ship- ton, Richard Clegg, Luo Mai, Pietro Bressana, Robert Soulé, Richard Mortier, Paolo Costa, Peter Pietzuch, Jon Crowcroft, Andrew W Moore, and Noa Zilberman. 2017. Emu: Rapid Prototyping of Networking Ser- vi...

    2017

  50. [59]

    Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ignacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, and Yiannis Psaras. 2022. De- sign and Evaluation of IPFS: A Storage Layer for the Decentralized Web. InProceedings of the ACM SIGCOMM 2022 Conference(Amsterdam, Netherlands...

    2022

  51. [60]

    Vytautas Tumas, Sean Rivera, Damien Magoni, and Radu State. 2023. Topology Analysis of the XRP Ledger. InProceedings of the 38th ACM/SIGAPP Symposium on Applied Computing(Tallinn, Estonia) (SAC ’23). Association for Computing Machinery, New York, NY, USA, 1277–1284. doi:10.114...

    2023

  52. [61]

    Yann Vonlanthen, Jakub Sliwinski, Massimo Albarello, and Roger Wat- tenhofer. 2024. Banyan: Fast Rotating Leader BFT. InProceedings of the 25th International Middleware Conference(Hong Kong, Hong Kong) (Middleware ’24). Association for Computing Machinery, New York, NY, USA, 4...

    2024

  53. [62]

    Reiter, Guy Golan Gueta, and Ittai Abraham

    Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abraham. 2019. HotStuff: BFT Consensus with Linearity and Responsiveness. InProceedings of the 2019 ACM Symposium on Prin- ciples of Distributed Computing(Toronto ON, Canada)(PODC ’19). Association for Co...

    2019

  54. [63]

    Siyuan Zhou and Shuai Mu. 2021. Fault-Tolerant Replication with Pull-Based Consensus in MongoDB. In18th USENIX Symposium on Networked Systems Design and Implementation (NSDI 21). USENIX Association, 687–703.https://www.usenix.org/conference/nsdi21/ presentation/zhou A Pseudoco...

    2021

  55. [1997]

    The macroscopic behavior of the TCP congestion avoidance algorithm.ACM SIGCOMM Computer Communication Review27, 3 (1997), 67–82

    1997

  56. [2015]

    In24th USENIX Security Symposium (USENIX Security 15)

    Eclipse Attacks on Bitcoin’s Peer-to-Peer Network. In24th USENIX Security Symposium (USENIX Security 15). 129–144

  57. [2020]

    arXiv:2003.03052https://arxiv.org/abs/2003.03052

    Combining GHOST and Casper.CoRRabs/2003.03052 (2020). arXiv:2003.03052https://arxiv.org/abs/2003.03052

    2003 arXiv

Pith tools

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