Pith. sign in

REVIEW 4 major objections 6 minor 3 cited by

Fides: Secure and Scalable Asynchronous DAG Consensus via Trusted Components

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

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

Pith's one-line read Fides claims asynchronous DAG-based BFT can run with n=2f+1 replicas and only f+1 references per vertex, using TEE-based broadcast, validation, coin, and transaction disclosure.

desk verdict The liveness proof collapses at Lemma 6—the counterexample is real—but the TEE-plus-DAG combination is new enough to warrant a careful look and a chance to fix. read the letter →

arxiv 2501.01062 v4 pith:VX22O6DD submitted 2025-01-02 cs.DC cs.DB

Shaokang Xie , Dakai Kang , Hanzheng Lyu , Jianyu Niu , Mohammad Sadoghi This is my paper · ORCID
classification cs.DCcs.DB
keywords asynchronousBFTconsensusDAG-basedtrustedexecutionenvironmentreliablebroadcastcommoncoinquorumsizecensorshipresistanceliveness
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

Fides proposes a way to make asynchronous DAG-based Byzantine fault tolerant consensus cheaper and faster by moving four critical operations into trusted execution environments. The paper's central claim is that with a TEE-assisted reliable broadcast and a TEE-assisted common coin, replicas can build a DAG in which each vertex references only $f+1$ vertices from the previous round, while still tolerating $f$ Byzantine replicas out of $n = 2f+1$. On that structure Fides defines a three-round wave and a commit rule that, the paper argues, commits a wave leader every three rounds in expectation under random delays and every six rounds under an asynchronous adversary. If correct, this would reduce quorum size, communication complexity, and commit latency relative to DAG protocols that require $n = 3f+1$ or threshold-signature coins, and the encrypted-transaction mechanism would resist front-running. The price is a threat model that trusts the enclave itself.

What carries the argument

The load-bearing object is the three-round wave with strong edges cut down to $f+1$ references. A strong edge from a round-$r$ vertex to a round-$(r-1)$ vertex counts toward the quorum that lets a replica advance; weak edges only help ensure every vertex is eventually included in some causal history. The commit rule uses the TEE-assisted common coin on the third round to elect a first-round leader, then checks whether at least $f+1$ third-round vertices reach that leader via strong paths; if not, the leader is skipped and a later committed leader recursively pulls in earlier waves. The monotonic counter inside the TEE is what makes each replica's per-round vertex unique, which is what lets a single echo phase replace the multiple all-to-all phases of classic reliable broadcast and what allows the system to run at $n = 2f+1$.

What would settle it

Construct a concrete $n=5$, $f=2$ DAG in which two second-round vertices reference disjoint pairs of first-round vertices and a third-round vertex references both second-round vertices, making its reachable first-round set larger than $f+1$; check whether every such third-round vertex still shares at least $f+1$ first-round ancestors. If a completed wave can have no first-round vertex with $f+1$ strong-path supporters, the expected commit-rate analysis fails.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that the reference requirement in asynchronous DAG consensus can be weakened from $2f+1$ to $f+1$ per vertex without losing safety or liveness, if trusted components supply three things: a monotonic counter that makes each replica's per-round proposal unique, a validator that certifies quorum references before a replica advances rounds, and a shared unpredictable random source for leader election. Fides packages these as four TEE components and arranges the DAG in waves of three rounds: first-round vertices are proposals, second- and third-round vertices vote by strong references, and the third round uses the common coin to elect a first-round leader. A leader commits directly when at least $f+1$ third-round vertices have a strong path to it, and indirectly through later committed leaders otherwise; the causal history of committed leaders is then ordered deterministically. The paper argues this yields $n = 2f+1$ Byzantine fault tolerance, $O(\kappa n^2 + n^3)$ metadata communication complexity, and expected leader commitment every three rounds under random delays.

Load-bearing premise

The liveness proof assumes that quorum intersection alone forces all second-round vertices of a wave to reference the same set of $f+1$ first-round vertices, so that every third-round vertex reaches that same set; this 'same set' consequence does not follow from intersection, and the six-round commit bound depends on it.

Editorial extensions

If this is right

  • If the central claim holds, Fides would combine $2f+1$ resilience with $f+1$ references per vertex, roughly halving the per-vertex metadata and the quorum size of the DAG protocols this work builds on.
  • The four-round commit rule would give the theoretically minimal commit latency for this DAG structure, with a leader committed every three rounds in expectation under random delays.
  • The TEE-assisted common coin removes threshold signatures from the critical path, so leader election adds no extra communication rounds beyond the DAG itself.
  • Transaction encryption until the commitment point would make front-running impossible for replicas, since they cannot read payloads before ordering is fixed.
  • The reported throughput figures (up to 400k tx/s geo-distributed and 810k tx/s local) would make the protocol practical for permissioned high-throughput deployments.

Reading between the lines

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

  • If the liveness proof gap in Lemma 6 can be closed, the same three-round wave and $f+1$ reference rule might be portable to non-TEE settings, replacing the trusted counter with digital signatures or erasure-coded broadcast at the cost of extra communication.
  • The three-round expected commit bound is derived under random message delays; an adversarial scheduler is credited with only a six-round bound, so a worst-case simulation could reveal whether the recursive commit rule ever stalls beyond that.
  • A small-$n$ configuration with $n=5, f=2$ shows that the 'same set' step inside Lemma 6 does not follow from quorum intersection alone; if that step fails, the liveness bound may need revision for small systems or the commit rule may need an extra condition.
  • The censorship-resistance guarantee depends on decryption happening strictly after ordering inside the TEE; an empirical test would be to submit timed transactions and check whether any replica can learn a payload before its vertex is committed.
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

4 major / 6 minor

Summary. Fides is an asynchronous DAG-based BFT consensus protocol that uses four TEE-assisted components (MIC-based reliable broadcast, RAC-based vertex validation, RANG-based common coin, and TRAD-based transaction disclosure) to tolerate f Byzantine faults among n=2f+1 replicas while using only f+1 strong references per vertex. The paper proposes three-round waves with a commit rule and claims that a vertex leader is committed every three rounds under random delays and every six rounds under an asynchronous adversary, with O(κn²+n³) metadata communication. The manuscript contains a formal correctness appendix (Appendix A) and an experimental evaluation on LAN, WAN, and delay-injected networks comparing Fides with Tusk, RCC, HotStuff, and PBFT.

Significance. If the claims held, Fides would be a substantial contribution: it would improve the quorum size and reference degree for asynchronous DAG consensus, replace threshold-signature common coins with a lightweight TEE primitive, and demonstrate large throughput gains on a real implementation. The authors deserve credit for specifying four trusted components, for attempting a complete correctness appendix, and for a broad evaluation. However, the central formal claims are not established. In particular, the key liveness lemma is false, the one-echo reliable broadcast does not satisfy its stated Agreement property as written, and the common-coin unpredictability guarantee is not delivered by the deterministic shared-seed RANG described in the paper. These are not presentation issues; they undermine the safety and liveness theorems as stated.

major comments (4)
  1. [Appendix A.4.2 (Lemma 6)] The proof of Lemma 6 is invalid and the lemma is false. In Case 2 the identity |U(V)| = |I(V)| + Σ_k (R(v_k)-|I(V)|) is not a set-theoretic identity, because the sets R(v_k)\I(V) need not be pairwise disjoint. More decisively, for n=5, f=2 consider first-round vertices {1,2,3,4,5}, second-round vertices A={1,2,3}, B={1,2,4}, C={1,2,5}, D={3,4,5}, E={1,3,5}, and third-round vertices T1={A,B,D}, T2={A,C,E}, T3={B,C,D}. Every vertex has exactly f+1=3 strong edges to the previous round, so this is a valid wave under the rules of §6.1. The first-round sets strongly reachable from T1, T2, and T3 are {1,2,3,4}, {1,2,3,5}, and {1,2,4,5}; their intersection contains only {1,2}. Hence only two, not f+1=3, first-round vertices are reachable from at least f+1 third-round vertices. The commit rule would elect a leader among the other three with positive probability. Lemma 7, Lemma 9, and Theorem 2 all invoke Lemma 6, so the claimed six-round expected commit and the liveness theorem are not established.
  2. [§5.1 and Theorem A.3] The one-echo reliable broadcast does not satisfy the Agreement property as written. The pseudocode in Fig. 3 delivers upon receiving at least 1 ⟨echo,v⟩ (line 10). A Byzantine replica can send an echo of a valid vertex to a single correct replica and to no one else; similarly, a Byzantine source can create a valid MIC-certified vertex and send the proposal only to that Byzantine echoer. The correct replica then delivers v while no other correct replica does. The proof of Theorem A.3 states that a correct replica 'must have received at least one valid ⟨echo,v⟩ from a correct replica', but the protocol does not require or verify that the echo is from a correct replica, and the validity check concerns v's certificate, not the echoer's provenance. Requiring f+1 matching echoes from distinct replicas would repair this specific step (giving at least one correct echoer that broadcasts to all), but that is not the protocol presented. Because Lemma 1 (identical DAGs) is derived from T-RBC Agreement, this flaw affects safety as well as liveness.
  3. [§5.3 and Theorem A.6] The RANG common coin does not provide Unpredictability as defined in §3.3. RANG is initialized with a shared seed from DKG and runs a deterministic PRNG; the interface Rand(round-cert) returns the leader as soon as a single valid round-certificate for the wave's final round is supplied. Any replica (honest or Byzantine) that has obtained such a round-cert can call Rand and learn the wave's leader before f+1 replicas have invoked ChooseLeader. Thus the outcome is not computationally indistinguishable from random while fewer than f+1 replicas have invoked the coin, contrary to the Unpredictability requirement. Lemma 7's probabilistic liveness argument assumes the adversary cannot predict the coin before the leader is revealed; with early prediction, the adversary can arrange the DAG so that the elected leader is among the vertices that do not satisfy the commit rule (as in the Lemma 6 counterexample).
  4. [Appendix A.4.2 (Lemma 8)] Lemma 8's stochastic model is not derived from the protocol. The proof assumes each second-round vertex independently points to the leader with probability p=(f+1)/(2f+1) and that third-round vertices independently sample f+1 second-round vertices; but in §6.1 a replica's strong edges are determined by the f+1 vertices currently in its local DAG at the moment it advances, with an adversarial (or arbitrary) delivery order. The protocol does not select references uniformly at random. Therefore the binomial computation and the lower bound 0.965 are properties of an assumed random-reference model, not of Fides. If the authors intend Lemma 8 as a performance statement under a specific stochastic network model, that model must be defined precisely and connected to the protocol; as written, the lemma does not support the claimed three-round expected commit latency.
minor comments (6)
  1. [Conclusion] The phrase 'in cenributed networks' should read 'in distributed networks'.
  2. [Fig. 4] The comment for weak edges says they 'represent strong edges'; it should say they represent weak edges.
  3. [Fig. 5] Line 25 contains the typo 'Deqeue' instead of 'Dequeue', and lines 65 and 70 use the symbol 'Ð' where set union/cup is intended.
  4. [References] Reference [51] contains a corrupted author name ('Michał undefinedwiundefinedtek'); please restore the correct Aleph author list.
  5. [§7.4] The measured value of 3.54 rounds to commit per vertex for Fides should be reconciled with the theoretical claims of 3 rounds (Lemma 8) and 6 rounds (Lemma 7), since the discrepancy is not explained.
  6. [Abstract] The claimed complexity O(κn²+n³) is not defined in the body; please provide the definitions of κ and the message-accounting that yields this expression.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: Fides derives its guarantees from explicit structural and TEE assumptions, with no fitted inputs or load-bearing self-citations.

full rationale

Fides contains no fitted parameters, no calibration set, and no quantity that is both an input and an output. The DAG construction, commit rule, and TEE components (MIC, RAC, RANG, TRAD) are introduced as explicit assumptions/primitives; safety (Theorem 1) and liveness (Theorem 2) are then argued from those assumptions in Appendix A. The TEE common coin is treated as a modular primitive whose agreement, termination, unpredictability, and fairness are proven from the RANG interface and the TEE security assumption, rather than from the consensus properties it supports; this is a declared trust assumption, not a circular reduction. Self-citations (ResilientDB [6,24], RCC [27], and [58]) appear as implementation platform or evaluation baselines and do not carry the correctness argument. The main flagged weakness is Appendix A.4.2, Lemma 6: the proof contains a garbled set-theoretic line ('|U(V)| = |I(V)| + ...') and asserts the key 'same set ... due to intersection' conclusion without a complete derivation; the liveness lemmas (7-9) and Theorem 2 depend on this step. This is a potential soundness gap, not an instance of circularity: the conclusion is not equivalent by construction to an input, and no fitted value is renamed as a prediction. The abstract's list of outperformed baselines (Bullshark, Mysticeti, Damysus, Achilles, HybridSet) is also broader than the protocols reported in Sec. 7 (Tusk, RCC, HotStuff, PBFT), another evidence gap external to circularity. Overall, no derivation reduces to its own inputs.

Assumptions & free parameters 0 free parameters · 5 assumptions · 4 invented entities

The central protocol rests on a small set of TEE trust assumptions, the asynchronous network model, and several unproven internal claims. No free parameters are fitted to data. Four trusted components are introduced as new entities, all validated only by the paper's own arguments. The liveness proof depends on Lemma 6, which is not established, and on a stochastic analysis that does not match the adversarial model.

assumptions (5)
  • domain assumption TEEs guarantee integrity, confidentiality, secure remote attestation, and are untamperable by a root-level host; rollback and side-channel attacks are mitigated by external means.
    Stated in Sec. 3.1 and used by MIC, RAC, RANG, and TRAD in all of Sec. 5.
  • domain assumption Messages between replicas are never lost and are delivered after arbitrary finite delay.
    Asynchronous network model in Sec. 3.1; used in Validity/Agreement proofs and DAG convergence (Claim 1, Lemma 1).
  • domain assumption RANG's shared-seed PRNG output is uniform and unpredictable without a valid round-cert.
    Assumed in Sec. 5.3, Theorem A.6 and A.7; needed for common-coin agreement, termination, unpredictability and fairness.
  • ad hoc to paper The set-intersection step in Lemma 6 is valid: it forces at least f+1 first-round vertices to satisfy the commit rule.
    This is the load-bearing step for liveness; the proof only states 'due to intersection' without a complete argument. If this step is wrong, the liveness lower bound (Lemma 7) does not follow.
  • ad hoc to paper Random message delays are representative of the asynchronous adversarial model for liveness analysis.
    Lemma 8 uses a binomial probability calculation over random delays to claim a commit every three rounds, but this does not match the definition of asynchrony in Sec. 3.1 where an adversary controls delays.
invented entities (4)
  • MIC (Monotonically Increasing Counter)
    purpose: Prevents equivocation by issuing a unique verifiable counter per round per replica inside the TEE, enabling one-echo reliable broadcast with n=2f+1.
    Introduced in Sec. 5.1; no external implementation or formal verification is provided beyond the paper's own description.
  • RAC (Round Advancement Certifier)
    purpose: Validates that a replica references at least f+1 reliably-delivered vertices and issues a round certificate for round advancement.
    Sec. 5.2; the certificate is the basis for vertex validation and for gating RANG access, but its correctness is only argued in the paper.
  • RANG (Random Number Generator)
    purpose: Implements a lightweight common coin for leader election using a shared seed and eligibility checks.
    Sec. 5.3; it claims the common coin properties but relies on the TEE state isolation and the correctness of the seed distribution, with no external verification.
  • TRAD (Transaction RSA Decryptor)
    purpose: Delays decryption of transactions until a vertex is committed, providing censorship resistance.
    Sec. 5.4; it uses a shared RSA key and per-client AES keys; the security argument is informal.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Fides: Secure and Scalable Asynchronous DAG Consensus via Trusted Components." pith.science (2026). https://pith.science/paper/VX22O6DD

@misc{pith2026250101062,
  author       = {Pith},
  title        = {Pith review of: Fides: Secure and Scalable Asynchronous DAG Consensus via Trusted Components},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VX22O6DD}},
  note         = {Machine review of arXiv:2501.01062}
}
abstract

DAG-based BFT consensus has attracted growing interest in distributed data management systems for consistent replication in untrusted settings due to its high throughput and resilience to asynchrony. However, existing protocols still suffer from high communication overhead and long commit latency. In parallel, introducing minimal hardware trust has proven effective in reducing the complexity of BFT consensus. Inspired by these works, we present Fides, an asynchronous DAG-based BFT consensus protocol that, to our knowledge, is among the first to leverage TEEs to enhance both scalability and efficiency. Fides tolerates a minority of Byzantine replicas and achieves $O(\kappa n^2 + n^3)$ metadata communication complexity through a customized TEE-assisted Reliable Broadcast (T-RBC) primitive with linear communication complexity in one-step broadcast. Building on T-RBC, Fides redefines the DAG construction rules by reducing the reference requirement from $2f+1$ to $f+1$ between consecutive vertices. This new structure weakens DAG connectivity and invalidates traditional commit rules, so we formally abstract the problem and derive new theoretical bounds of liveness. We further propose a four-round commit rule that achieves the theoretically minimal commit latency. Besides, we design two additional primitives, T-RoundCert and T-Coin, to efficiently certify DAG references and replace the costly cryptographic common coin used in prior protocols. Comprehensive evaluations on geo-distributed and local testbeds show that Fides substantially outperforms state-of-the-art protocols, including Tusk, Bullshark, Mysticeti, RCC, Damysus, Achilles and HybridSet, achieving lower latency and higher throughput while preserving strong safety and liveness guarantees.

Figures

Figures reproduced from arXiv: 2501.01062 by the authors.

Figure 1
Figure 1. Example of commit rule in Fides. If the leader has less than 𝑓 + 1 references from its third round (red in the figure), they are ignored; otherwise (blue in the figure), the algorithm searches the causal DAG to commit all preceding leaders (dark yellow and red in the figure) and totally orders the rest of the DAG by the predefined rule afterward. coin ensures robustness against bias or manipulation, thereby maintain… view at source ↗
Figure 2
Figure 2. Overview Architecture of Fides to keep transaction content encrypted throughout the entire con￾sensus process (Sec. 6.3). 4.1 Consensus Flow We present a high-level flow to process client transactions ( [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. TEE-Assisted Reliable Broadcast with MIC Reliable Broadcast [48], require three rounds of all-to-all communi￾cation and a replication factor of 𝑛 = 3𝑓 + 1 to tolerate 𝑓 Byzantine faults. While reliable, these protocols impose substantial communi￾cation overhead. By integrating MIC, Fides optimizes the reliable broadcast process, effectively reducing both communication over￾head and the quorum threshold to 𝑛 = 2𝑓 +1.… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Data Structures and basic utilities for replica [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: Pseudocode for DAG construction A key improvement of Fides is the utilization of this lightweight common coin to generate globally consistent random values for leader election. This coin introduces negligible computational and communication overhead, ensuring efficient…
Figure 6
Figure 6. Figure 6: DAGs in Fides of its preceding causal history is transitively committed in a prede￾fined order (line 67, e.g., Deep-First Search, Breadth-First Search, etc.). However, due to potentially divergent views of the DAG among replicas or situations where a vertex fails to ga…
Figure 7
Figure 7. Figure 7: Pseudocode of Fides’s Byzantine Consensus 6.3 Censorship Resistance Ensuring censorship resistance is a critical challenge in blockchain systems, where transaction visibility can be exploited by malicious [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Pseudocode for Client-Side Workflow replicas to selectively include, exclude, or reorder transactions for unfair advantages. To address this, we propose a TEE-assisted Trans￾action Disclosure mechanism supported by TEE and dual-key en￾cryption mechanisms. This mechanis…
Figure 9
Figure 9. Figure 9: Impact of varying degrees of fault tolerance, batch sizes, and failures [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 10
Figure 10. Figure 10: Protocol Time Breakdown by Stage 7.4 System Breakdown To analyze protocol latency, we provide a breakdown of Fides (SGX mode) and Tusk in a DIN environment with a fault tolerance of 10. For fairness, transaction queuing latency is excluded. The break￾down is divided i…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Multimmit: Extending Blocks for Faster Finality

    cs.DC 2026-07 conditional novelty 7.0 of 10

    Multimmit finalises transaction blocks in one voting round with roughly 3δ average latency from dissemination, confining a faulty producer's damage to its own chain.

  2. Cassandra: Consensus with Partial Progress via Robust Partitionable View Synchronization

    cs.DC 2026-07 accept novelty 6.5 of 10

    Cassandra enables safety-preserving partial progress under network partitions via two-tier (PoA/PoR) certification, multi-proposer priority, and a weak-quorum decoupled pacemaker, while matching SOTA throughput when t...

  3. Not eXactly Byzantine: Efficient and Resilient TEE-Based State Machine Replication

    cs.DC 2025-01 conditional novelty 6.0 of 10

    NxBFT is a TEE-based, asynchronous, leaderless DAG consensus protocol that achieves the highest throughput in the authors' comparison against MinBFT and Chained-Damysus for up to 40 replicas, at the cost of higher lat...

Reference graph

Works this paper leans on

60 extracted references · 55 canonical work pages · cited by 3 Pith papers

  1. [1]

    https://cybernews.com/crypto/flash-boys-2-0-front-runners-draining- 280-million-per-month-from-crypto-transactions

    Cybernews: Front Runners Draining $280 Million per Month from Crypto Trans- actions. https://cybernews.com/crypto/flash-boys-2-0-front-runners-draining- 280-million-per-month-from-crypto-transactions. (Accessed: 2024-11-28)

    work page 2024

  2. [2]

    SGX Remote Attestation

    Intel. SGX Remote Attestation. https://www.intel.com/content/www/us/en/ developer/tools/software-guard-extensions/attestation-services.html. (Accessed: 2024-11-28)

    work page 2024

  3. [3]

    SEV Remote Attestation

    AMD. SEV Remote Attestation. https://enarx.dev/docs/technical/amd-sev- attestation. (Accessed: 2024-11-28)

    work page 2024

  4. [4]

    Software Security Guidance

    Intel. Software Security Guidance. https://www.intel.com/content/www/us/en/ developer/topic-technology/software-security-guidance/overview.html. (Ac- cessed: 2024-11-28)

    work page 2024

  5. [5]

    https://www.intel.com/content/www/us/en/developer/articles/training/usage- of-simulation-mode-in-sgx-enhanced-application.html

    How to Run Intel ® Software Guard Extensions’ Simulation Mode. https://www.intel.com/content/www/us/en/developer/articles/training/usage- of-simulation-mode-in-sgx-enhanced-application.html. (Accessed: 2024-11-28)

    work page 2024

  6. [6]

    https://resilientdb.incubator.apache.org/

    Apache ResilientDB (Incubating). https://resilientdb.incubator.apache.org/. (Ac- cessed: 2024-11-28). Shaokang Xie1, Dakai Kang 1, Hanzheng Lyu 2, Jianyu Niu 3, Mohammad Sadoghi 1

    work page 2024

  7. [7]

    https://openenclave.io

    Open Enclave SDK. https://openenclave.io. (Accessed: 2024-11-28)

    work page 2024

  8. [8]

    Practical Byzantine Fault Tolerance

    Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance. In OSDI, 1999

    work page 1999

Show all 60 references
  1. [9]

    Consensus in the Presence of Partial Synchrony

    Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer. Consensus in the Presence of Partial Synchrony. In JACM, 1988

    1988

  2. [10]

    Unreliable Failure Detectors for Reliable Distributed Systems

    Tushar Deepak Chandra and Sam Toueg. Unreliable Failure Detectors for Reliable Distributed Systems. In JACM, 1996

    1996

  3. [11]

    Predicate Detection Modality and Seman- tics in Three Partially Synchronous Models

    Chunbo Chu and Monica Brockmeyer. Predicate Detection Modality and Seman- tics in Three Partially Synchronous Models. In ICIS, 2008

    2008

  4. [12]

    Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults

    Allen Clement, Edmund Wong, Lorenzo Alvisi, Mike Dahlin, and Mirco Marchetti. Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults. In NSDI, 2009

    2009

  5. [13]

    FnF-BFT: Exploring Performance Limits of BFT Protocols

    Zeta Avarikioti, Lioba Heimbach, Roland Schmid, Laurent Vanbever, Roger Wat- tenhofer, and Patrick Wintermeyer. FnF-BFT: Exploring Performance Limits of BFT Protocols. In arXiv preprint arXiv:2009.02235, 2020

    2009 arXiv

  6. [14]

    Fever: Optimal Responsive View Syn- chronisation

    Andrew Lewis-Pye and Ittai Abraham. Fever: Optimal Responsive View Syn- chronisation. In arXiv preprint arXiv:2301.09881, 2023

    2023 arXiv

  7. [15]

    The Honey Badger of BFT Protocols

    Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The Honey Badger of BFT Protocols. In CCS, 2016

    2016

  8. [16]

    Asymptotically Opti- mal Validated Asynchronous Byzantine Agreement

    Ittai Abraham, Dahlia Malkhi, and Alexander Spiegelman. Asymptotically Opti- mal Validated Asynchronous Byzantine Agreement. In PODC, 2019

    2019

  9. [17]

    Dumbo-NG: Fast Asynchronous BFT Consensus with Throughput-Oblivious Latency

    Yingzi Gao, Yuan Lu, Zhenliang Lu, Qiang Tang, Jing Xu, and Zhenfeng Zhang. Dumbo-NG: Fast Asynchronous BFT Consensus with Throughput-Oblivious Latency. In CCS, 2022

    2022

  10. [18]

    Dumbo-MVBA: Optimal Multi-valued Validated Asynchronous Byzantine Agreement, Revisited

    Yuan Lu, Zhenliang Lu, Qiang Tang, and Guiling Wang. Dumbo-MVBA: Optimal Multi-valued Validated Asynchronous Byzantine Agreement, Revisited. InPODC, 2020

    2020

  11. [19]

    All You Need is DAG

    Idit Keidar, Eleftherios Kokoris-Kogias, Oded Naor, and Alexander Spiegelman. All You Need is DAG. In PODC, 2021

    2021

  12. [20]

    Bullshark: DAG BFT Protocols Made Practical

    Alexander Spiegelman, Neil Giridharan, Alberto Sonnino, and Lefteris Kokoris- Kogias. Bullshark: DAG BFT Protocols Made Practical. In CCS, 2022

    2022

  13. [21]

    Shoal: Im- proving DAG-BFT Latency and Robustness

    Alexander Spiegelman, Balaji Aurn, Rati Gelashvili, and Zekun Li. Shoal: Im- proving DAG-BFT Latency and Robustness. In FC, 2024

    2024

  14. [22]

    Blue fish, red fish, live fish, dead fish

    Victor Shoup. Blue fish, red fish, live fish, dead fish. In Cryptology ePrint Archive, Paper 2024/1235, 2024

    2024

  15. [23]

    The latency price of threshold cryptosystem in blockchains

    Zhuolun Xiang, Sourav Das, Zekun Li, Zhoujun Ma, and Alexander Spiegelman. The latency price of threshold cryptosystem in blockchains. In arXiv preprint arXiv:2407.12172, 2024

    2024 arXiv

  16. [24]

    Qadah, Jelle Hellings, and Mohammad Sadoghi

    Sajjad Rahnama, Suyash Gupta, Thamir M. Qadah, Jelle Hellings, and Mohammad Sadoghi. Scalable, Resilient, and Configurable Permissioned Blockchain Fabric. In PVLDB, 2020

    2020

  17. [25]

    Intel SGX Explained

    Victor Costan and Srinivas Devadas. Intel SGX Explained. In Cryptology ePrint Archive, Paper 2016/086, 2016

    2016

  18. [26]

    Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexander Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. In EuroSys, 2022

    2022

  19. [27]

    RCC: Resilient Concur- rent Consensus for High-Throughput Secure Transaction Processing

    Suyash Gupta, Jelle Hellings, and Mohammad Sadoghi. RCC: Resilient Concur- rent Consensus for High-Throughput Secure Transaction Processing. In ICDE, 2021

    2021

  20. [28]

    Reiter, Guy Golan Gueta, and Ittai Abra- ham

    Maofan Yin, Dahlia Malkhi, Michael K. Reiter, Guy Golan Gueta, and Ittai Abra- ham. HotStuff: BFT Consensus with Linearity and Responsiveness. In PODC, 2019

    2019

  21. [29]

    No Fish Is Too Big for Flash Boys! Frontrunning on DAG-based Blockchains

    Jianting Zhang and Aniket Kate. No Fish Is Too Big for Flash Boys! Frontrunning on DAG-based Blockchains. In Cryptology ePrint Archive, 2024

    2024

  22. [30]

    BBCA-CHAIN: One-Message, Low Latency BFT Consensus on a DAG

    Dahlia Malkhi, Chrysoula Stathakopoulou, and Maofan Yin. BBCA-CHAIN: One-Message, Low Latency BFT Consensus on a DAG. In FC, 2024

    2024

  23. [31]

    Mysticeti: Reaching the Limits of Latency with Uncertified DAGs

    Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, and Mingwei Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs. In arXiv preprint arXiv:2310.14821, 2024

  24. [32]

    Sailfish: Towards improving the latency of DAG-based BFT

    Nibesh Shrestha, Rohan Shrothrium, Aniket Kate, and Kartik Nayak. Sailfish: Towards improving the latency of DAG-based BFT. In S&P, 2025

    2025

  25. [33]

    Hybrids on Steroids: SGX- Based High Performance BFT

    Johannes Behl, Tobias Distler, and Rüdiger Kapitza. Hybrids on Steroids: SGX- Based High Performance BFT. In EuroSys, 2017

    2017

  26. [34]

    Efficient Byzantine Fault-Tolerance

    Giuliana Veronese, Miguel Correia, Alysson Bessani, Lau Lung, and Paulo Verís- simo. Efficient Byzantine Fault-Tolerance. In TC, 2013

    2013

  27. [35]

    DAMY- SUS: Streamlined BFT Consensus Leveraging Trusted Components

    Jérémie Decouchant, David Kozhaya, Vincent Rahli, and Jiangshan Yu. DAMY- SUS: Streamlined BFT Consensus Leveraging Trusted Components. In EuroSys, 2022

    2022

  28. [36]

    Scalable Byzantine Fault Tolerance via Partial Decentralization

    Balaji Arun and Binoy Ravindran. Scalable Byzantine Fault Tolerance via Partial Decentralization. In PVLDB, 2022

    2022

  29. [37]

    TBFT: Efficient Byzantine Fault Tolerance Using Trusted Execution Environment

    Jiashuo Zhang, Jianbo Gao, Ke Wang, Zhenhao Wu, Yue Li, Zhi Guan, and Zhong Chen. TBFT: Efficient Byzantine Fault Tolerance Using Trusted Execution Environment. In ICC, 2022

    2022

  30. [38]

    ROTE: Rollback Protection for Trusted Execution

    Sinisa Matetic, Mansoor Ahmed, Kari Kostiainen, Aritra Dhar, David Sommer, Arthur Gervais, Ari Juels, and Srdjan Capkun. ROTE: Rollback Protection for Trusted Execution. In Security, 2017

    2017

  31. [39]

    Nimble: Rollback Protection for Confidential Cloud Services

    Sebastian Angel, Aditya Basu, Weidong Cui, Trent Jaeger, Stella Lau, Srinath Setty, and Sudheesh Singanamalla. Nimble: Rollback Protection for Confidential Cloud Services. In OSDI, 2023

    2023

  32. [40]

    Rollback and Forking Detection for Trusted Execution Environments using Lightweight Collective Memory

    Marcus Brandenburger, Christian Cachin, Matthias Lorenz, and Rüdiger Kapitza. Rollback and Forking Detection for Trusted Execution Environments using Lightweight Collective Memory. In DSN, 2017

    2017

  33. [41]

    Guoxing Chen, Sanchuan Chen, Yuan Xiao, Yinqian Zhang, Zhiqiang Lin, and Ten H. Lai. SgxPectre: Stealing Intel Secrets from SGX Enclaves Via Speculative Execution. In S&P, 2019

    2019

  34. [42]

    RIDL: Rogue In-Flight Data Load

    Stephan Schaik, Alyssa Milburn, Sebastian Österlund, Pietro Frigo, Giorgi Maisuradze, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida. RIDL: Rogue In-Flight Data Load. In S&P, 2019

    2019

  35. [43]

    ZombieLoad: Cross-Privilege-Boundary Data Sampling

    Michael Schwarz, Moritz Lipp, Daniel Moghimi, Jo Van Bulck, Julian Stecklina, Thomas Prescher, and Daniel Gruss. ZombieLoad: Cross-Privilege-Boundary Data Sampling. In CCS, 2019

    2019

  36. [44]

    CacheBleed: A Timing Attack on OpenSSL Constant Time RSA

    Yuval Yarom, Daniel Genkin, and Nadia Heninger. CacheBleed: A Timing Attack on OpenSSL Constant Time RSA. In CHES, 2016

    2016

  37. [45]

    Introduction to Modern Cryptography (2nd edition)

    Jonathan Katz and Yehuda Lindell. Introduction to Modern Cryptography (2nd edition). In Chapman and Hall/CRC, 2014

    2014

  38. [46]

    On the diversity of asynchronous communication

    Florent Chevrou, Aurélie Hurault, and Philippe Quéinnec. On the diversity of asynchronous communication. In FAC, 2016

    2016

  39. [47]

    Shoal++: High Throughput DAG BFT Can Be Fast! In arXiv preprint arXiv:2405.20488, 2024

    Balaji Arun, Zekun Li, Florian Suri-Payer, Sourav Das, and Alexander Spiegel- man. Shoal++: High Throughput DAG BFT Can Be Fast! In arXiv preprint arXiv:2405.20488, 2024

    2024 arXiv

  40. [48]

    Asynchronous Byzantine Agreement Protocols

    Gabriel Bracha. Asynchronous Byzantine Agreement Protocols. In Inf. Comput., 1987

    1987

  41. [49]

    How to Share a Secret

    Adi Shamir. How to Share a Secret. In CACM, 1979

    1979

  42. [50]

    The Hashgraph Protocol: Efficient Asynchronous BFT for High-Throughput Distributed Ledgers

    Leemon Baird and Atul Luykx. The Hashgraph Protocol: Efficient Asynchronous BFT for High-Throughput Distributed Ledgers. In COINS, 2016

    2016

  43. [51]

    Aleph: Efficient Atomic Broadcast in Asynchronous Networks with Byzantine Nodes

    Adam Gagol, Damian Leśniak, Damian Straszak, and Michał undefinedwiunde- finedtek. Aleph: Efficient Atomic Broadcast in Asynchronous Networks with Byzantine Nodes. In AFT, 2019

    2019

  44. [52]

    Mahi-mahi: Low-latency asynchronous BFT DAG-based consensus

    Philipp Jovanovic, Lefteris Kokoris Kogias, Bryan Kumara, Alberto Sonnino, Pasindu Tennage, and Igor Zablotchi. Mahi-mahi: Low-latency asynchronous BFT DAG-based consensus. In arXiv preprint arXiv:2410.08670, 2024

    2024 arXiv

  45. [53]

    Maximal Extractable Value (MEV) Protection on a DAG

    Dahlia Malkhi and Pawel Szalachowski. Maximal Extractable Value (MEV) Protection on a DAG. In SBC, 2022

    2022

  46. [54]

    Autobahn: Seamless high speed bft

    Neil Giridharan, Florian Suri-Payer, Ittai Abraham, Lorenzo Alvisi, and Natacha Crooks. Autobahn: Seamless high speed bft. In SOSP, 2024

    2024

  47. [55]

    GradedDAG: An Asynchronous DAG-based BFT Consensus with Lower Latency

    Xiaohai Dai, Zhaonan Zhang, Jiang Xiao, Jingtao Yue, Xia Xie, and Hai Jin. GradedDAG: An Asynchronous DAG-based BFT Consensus with Lower Latency. In SRDS, 2024

    2024

  48. [56]

    LightDAG: A Low-latency DAG-based BFT Consensus through Lightweight Broadcast

    Xiaohai Dai, Guanxiong Wang, Jiang Xiao, Zhengxuan Guo, Rui Hao, Xia Xie, and Hai Jin. LightDAG: A Low-latency DAG-based BFT Consensus through Lightweight Broadcast. In IPDPS, 2024

    2024

  49. [57]

    Douceur, Jacob R

    Dave Levin, John R. Douceur, Jacob R. Lorch, and Thomas Moscibroda. TrInc: Small Trusted Hardware for Large Distributed Systems. In NSDI, 2009

    2009

  50. [58]

    Dissecting BFT Consensus: In Trusted Components we Trust! In EuroSys, 2022

    Suyash Gupta, Sajjad Rahnama, Shubham Pandey, Natacha Crooks, and Moham- mad Sadoghi. Dissecting BFT Consensus: In Trusted Components we Trust! In EuroSys, 2022

    2022

  51. [59]

    OneShot: View-Adapting Streamlined BFT Protocols with Trusted Execution Environments

    Jérémie Decouchant, David Kozhaya, Vincent Rahli, and Jiangshan Yu. OneShot: View-Adapting Streamlined BFT Protocols with Trusted Execution Environments. In IPDPS, 2024

    2024

  52. [60]

    Trusted Hardware-Assisted Leaderless Byzantine Fault Tolerance Consensus

    Liangrong Zhao, Jérémie Decouchant, Joseph Liu, Qinghua Lu, and Jiangshan Yu. Trusted Hardware-Assisted Leaderless Byzantine Fault Tolerance Consensus. In TDSC, 2024. Fides: Scalable Censorship-Resistant DAG Consensus via Trusted Components A Correctness Analysis A.1 TEE-Assis...

    2024

Pith tools

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