Pith. sign in

REVIEW 4 major objections 4 minor 38 references

JUNO introduces aggregated vector consensus, a new asynchronous agreement primitive that decides each element of a vector separately, and uses it to build an asynchronous common subset protocol with optimal O(n^2) message complexity.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · deepseek-v4-flash

2026-08-03 10:53 UTC pith:6GYMKQKZ

load-bearing objection JUNO's vector batching is a real idea, but the protocol's core correctness is unproven and the validity definition is internally broken. the 4 major comments →

arxiv 2607.29244 v1 pith:6GYMKQKZ submitted 2026-07-31 cs.CR

JUNO: Aggregated Vector Consensus for Optimal Asynchronous Common Subset

Liangrong Zhao , Qin Wang , Joseph K. Liu , Jiangshan Yu This is my paper
classification cs.CR
keywords aggregated vector consensusasynchronous common subsetByzantine fault toleranceprovable broadcastvector consensusasynchronous agreementmessage complexityblockchain consensus
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to establish that asynchronous common subset (ACS) — the 'agree on a common set of transactions' problem underlying many blockchain and MPC protocols — can be solved with optimal O(n^2) message complexity while still processing each transaction's agreement independently. To do this it proposes a new primitive, aggregated vector consensus (AVC), in which processes exchange a single vector of per-transaction binary votes instead of running n separate agreement instances. JUNO combines this with a lightweight provable broadcast (PB) phase, replacing the heavier reliable broadcast used in classic BKR-style constructions. If the construction is correct, JUNO tolerates up to f Byzantine faults among 3f+1 processes in a fully asynchronous network and reports 93% higher throughput than HoneyBadgerBFT and 47% higher than Dory in evaluation.

Core claim

At the center of the paper is the claim that the classic BKR approach to asynchronous common subset — n parallel broadcast and agreement instances — can be compressed into a single 'aggregated vector consensus' without giving up per-transaction independence. Each correct process packs its n binary votes into one vector and sends that single message per round; the agreement protocol updates and decides each coordinate independently using threshold counts and a common coin. To keep the broadcast phase cheap, JUNO replaces reliable broadcast with a five-step provable broadcast (propose, endorse, lock, commit, deliver) that lacks total delivery; the loss is absorbed by a four-valued vote (1, 0,

What carries the argument

The central object is 'aggregated vector consensus': each process inputs a vector of n votes and correct processes decide a binary output vector index-by-index, with AVC-validity requiring that for every index, the decided value was proposed by at least one correct process. The carrying mechanism is the vote-vector message exchanged once per round in the agreement phase, plus a provable broadcast primitive whose five message types (Propose, Endorse, Lock, Commit, Deliver) let a process record its delivery stage as one of four vote values; the agreement rules apply threshold conditions and a shared common coin (optimistically set to 1 in round 1) to converge each coordinate. This machinery co

Load-bearing premise

The load-bearing premise is that the vote-update and decision rules in Algorithm 1 (lines 62–76) and the extra conversions stated for rounds after 5 in Section IV.C.1 — which the paper asserts without a proof — actually guarantee agreement, validity, and termination for every index x.

What would settle it

Simulate or formally model Algorithm 1 with n=4, f=1 and an adversarial message schedule that gives two correct processes different Vote-message sets at the same round; if a reachable state has one correct process decide 1 for some index x and another decide 0, or has the null-to-1 rule (lines 65–66) turn null votes into 1 without any correct process having proposed 1 for x, then AVC-validity or agreement fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If JUNO's construction is sound, ACS can reach the O(n^2) message-complexity lower bound without sacrificing per-transaction independence, closing a gap between the BKR and MVBA paradigms.
  • The cheaper provable broadcast can replace reliable broadcast in BKR-style ACS, removing the all-to-all communication bottleneck and reducing the broadcast phase to O(n) messages per transaction.
  • The aggregated vector consensus primitive may serve as a standalone building block for other asynchronous protocols that need agreement on a vector with independent coordinates.
  • Reported throughput gains over HoneyBadgerBFT and Dory suggest practical deployments could see substantial improvements, especially as batch size or fault tolerance f grows.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The authors leave implicit that the vector aggregation trick applies beyond binary votes: mapping multi-valued proposals onto indices would give a general coordinate-wise agreement primitive that could replace multiple ABA instances in any BKR-style protocol.
  • The four-valued vote scheme (1, 0, nil, null) is a generic way to encode partial progress in a broadcast whose sender may be faulty; it could transfer to other consensus protocols that want to avoid reliable broadcast's all-to-all cost.
  • A testable extension is to vary the common-coin schedule: the first round is hard-coded to coin=1, so a variant that flips the coin from the start would show whether the reported throughput gains come from that optimistic bias or from the aggregation itself.
  • Re-running the benchmarks under artificial network partitions or with a Byzantine sender that deliberately sends Lock but no Deliver would exercise the nil/null conversion rules that carry the protocol's liveness.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper introduces 'aggregated vector consensus' (AVC), a vector-valued agreement primitive in which each process inputs a vector and the output vector is aggregated from per-index votes, and 'JUNO,' an asynchronous common subset (ACS) protocol built on AVC together with a lightweight provable broadcast (PB) phase. The paper claims that JUNO achieves optimal O(n^2) message complexity for n parallel transactions, tolerates f < n/3 Byzantine processes, and that an implementation outperforms HoneyBadgerBFT by about 93% and Dory by about 47% in throughput. The manuscript describes the protocol in Algorithm 1 and Section IV, reports a message-complexity analysis in Section V.A, and gives experimental results. However, it contains no theorems or proofs establishing AVC agreement, termination, or validity, or ACS validity, agreement, and totality. Moreover, the vote-update rules in Algorithm 1 are internally inconsistent with the textual description in Section IV.C.1 and appear to violate the paper's own AVC-validity definition.

Significance. If the protocol were correct, the contribution would be meaningful: replacing RBC with a cheaper PB in the BKR paradigm while aggregating n parallel ABA instances into one vector agreement instance is a plausible route to O(n^2) ACS complexity, and the reported experimental comparison against HoneyBadgerBFT and Dory gives the work an applied dimension. The paper also correctly identifies a relevant gap: most vector-consensus constructions rely on synchrony or additional mechanisms, and adapting vector-style agreement to fully asynchronous ACS is non-trivial. These strengths are, however, entirely conditional on the correctness of the ad hoc vote-revision logic, and the manuscript does not supply the required proof. The evaluation cannot substitute for the missing formal argument, since the protocol as written is not a well-defined correct algorithm.

major comments (4)
  1. [Sections IV and V.A (no correctness proof)] The central claims—AVC agreement/termination/validity and ACS validity/agreement/totality—are never stated as theorems or proved. Section V.A only counts messages and states a claimed round count of 'logn'; it does not argue that the update rules guarantee agreement or termination. Algorithm 1 lines 62–76 are asserted to 'try to reach an agreement for each instance,' but no invariant, convergence argument, or validity argument is given. This absence is load-bearing because the protocol's entire contribution rests on these rules.
  2. [Definition 2 vs. Algorithm 1 lines 62–66] AVC-validity (Definition 2) requires each decided V[i] to equal V_j[i] for some correct process's input vector V_j. But line 65–66 sets v_i[x]←1 when there exist 2f+1 Vote messages with v[x]==null and coin==1. Since the coin is optimistically 1 in round 1, suppose f Byzantine processes and f+1 correct processes are in the null state for x while the remaining correct processes have not proposed 1. Then the condition is satisfiable, all correct processes set their vote to 1, and later decide 1, even though no correct process's input vector at x is 1. This violates Definition 2. If V_j[i] is instead reinterpreted as the final updated vote, the property becomes tautological and provides no safety guarantee.
  3. [Algorithm 1 lines 62–76 vs. Section IV.C.1] The pseudocode applies the update rules unconditionally in every round after receiving n−f Vote messages, whereas Section IV.C.1 states that the special conversions apply only 'if there is no decision made after Round 5.' The two rule sets also differ: for example, Section IV.C.1 says 'A 0 or nil vote can be converted to 1 upon receiving 2f+1 null votes if the common coin is 1,' while Algorithm 1 line 65 converts null to 1 without regard to the process's own previous vote. Since termination and validity depend on the exact rules, the protocol is under-specified and the discrepancy must be resolved.
  4. [Algorithm 1 lines 48–53 and Section III.C (PB-consistency)] A Deliver message is accepted by a process on the primary's signature and hash chain alone, with no attached proof of 2f+1 Commit messages (Algorithm 1 lines 48–53). The text in Section III.C and IV.A assumes as an axiom that PB-consistency holds for such messages, but no argument shows that a Byzantine primary cannot issue a valid-looking Deliver without actually collecting commits. The subsequent agreement phase treats a delivered transaction as a '1' vote, so this is a security-relevant gap. Similarly, the common coin used in line 60 is not instantiated or referenced; the termination and the O(log n) round expectation in Section V.A depend on an unspecified coin.
minor comments (4)
  1. [Figure 4c] The caption says 'Latency breakdown for JUNO & HoneyBadgerBFT,' but the legend and surrounding text compare JUNO with Dory. The caption should be corrected.
  2. [Section IV.B (vote definitions)] The text says a null vote is given 'when receiving a valid Lock message with 2f+1 endorsements,' but Algorithm 1 lines 40–47 verify only the Lock signature and its hash against the Propose; the receiver cannot check that the primary actually collected 2f+1 endorsements. The definition should be made consistent with what is verifiable in the pseudocode.
  3. [Section V.A] The phrase 'JUNO’ message complexity' is a typo, and the expression O(5n^2 + |m| n^2 log n) should clarify that the 'logn' factor is an expected round count and why this yields overall O(n^2) message complexity when each Vote message contains n binary elements. Without a theorem on the expected number of rounds, the claimed optimality is not substantiated.
  4. [References and abstract] References contain typos such as 'Retrived in https:// github.com/...' and inconsistent capitalization ('HoneybadgerBFT' vs 'HoneyBadgerBFT'). The abstract claims 'average throughput performance improvement of 93% compared with HoneyBadgerBFT and a 47% improvement compared with Dory,' but Section V.B reports these numbers only qualitatively across different f values; the averaging convention should be stated.

Circularity Check

0 steps flagged

No significant circularity: JUNO's O(n^2) and performance claims follow from its own message counts and external benchmarks; the sole author-overlapping citation (DAMYSUS) is related-work context and not load-bearing.

full rationale

The paper's central claims are (i) that JUNO implements a new aggregated vector consensus primitive with O(n^2) message complexity, and (ii) that it outperforms HoneyBadgerBFT and Dory. Neither reduces to its inputs. The O(n^2) agreement-phase bound is derived by counting messages: 'at each step of the agreement phase, each of the n processes sends only one vote message to each of the n recipients' (Sec. I), i.e., the complexity statement follows from the protocol's message pattern rather than being fitted. The 93%/47% throughput claims are benchmark results against open-source baselines on Google Cloud (Sec. V.B), i.e., external measurements, not fitted parameters renamed as predictions. There is no parameter fitting, no uniqueness theorem imported from the authors' prior work, and no ansatz smuggled in by self-citation. The only reference with overlapping authorship is DAMYSUS [37] (Jiangshan Yu), cited in the related-work paragraph on provable broadcast ('Provable broadcast protocols, which are employed in pipelined BFT systems [35][36][37]'); this citation is contextual and does not carry the correctness or performance argument, so it is not load-bearing. The paper does omit a full correctness proof for Algorithm 1 and contains unsupported assertions (e.g., Sec. IV.C.1: 'we assert that the relevant transaction is valid...'), and Definition 2's AVC-validity may be in tension with the null-to-1 update in Algorithm 1 lines 65-66; these are serious correctness risks, but they are not instances of circular reasoning by construction. Accordingly the circularity score is 2, reflecting only the presence of a non-load-bearing self-citation and the non-circular but unproven correctness gaps.

Axiom & Free-Parameter Ledger

0 free parameters · 4 axioms · 0 invented entities

The central claim rests on the standard asynchronous BFT model (Section III.A) plus three unvetted components: an uninstantiated common coin with an optimistic round-1 bias (Algorithm 1 line 60; Section IV.B); a provable-broadcast consistency guarantee that the coded Deliver (lines 48–53) does not actually enforce; and the correctness of ad hoc vote-update rules that exist in two inconsistent versions (Algorithm 1 lines 62–76 vs. Section IV.C.1). No numerical constants are fitted to data — the thresholds f, 2f+1, n−f follow from the n≥3f+1 model — and no new physical/system entities are invented; 'aggregated vector consensus' is a definition, not an entity with independent evidence. The ordering-window size (Section IV.C.2) is left unspecified ('set slightly higher').

axioms (4)
  • domain assumption Authenticated point-to-point channels in an asynchronous network; messages eventually delivered, arbitrarily delayed/reordered; up to f ≤ ⌊(n−1)/3⌋ Byzantine processes; cryptographic primitives secure.
    Section III.A states the model; standard for async BFT and not itself contentious.
  • domain assumption A common coin CommonCoin(n−f, σ, r) exists with agreement, unpredictability, and a termination argument of O(log n)/expected-O(1) rounds; the optimistic round-1 value 1 preserves liveness.
    Algorithm 1 line 60 ('coin←CommonCoin(n-f,σ,r)') and Step-⑧ (Section IV.B). The coin is never instantiated and the round-1 coin=1 optimism is asserted without an adversary analysis; the agreement-phase O(n²) count depends on the unstated round bound.
  • ad hoc to paper PB-consistency holds for a Deliver message verifiable from the primary's signature and hash chain alone (no attached 2f+1-commit proof).
    Section II.B.2 asserts PB-consistency from the PB literature; Algorithm 1 lines 48–53 verify only σ_p and the hash chain, so consistency is assumed rather than enforced. A Byzantine primary could otherwise deliver different hashes to different subsets.
  • ad hoc to paper The vote-update rules in Algorithm 1 lines 62–76 (and their Section IV.C.1 'after Round 5' variant) are correct: they preserve AVC-validity per element and guarantee agreement and termination.
    This is the unproved core: no theorem establishes it; the two rule versions differ; rule R2 (line 65–66) creates a 1 from 2f+1 nulls + coin=1 even when no correct process's initial vector contained a 1, which contradicts Definition 2 if V_j[i] is an initial input.

pith-pipeline@v1.3.0-daily-deepseek · 15163 in / 28408 out tokens · 261084 ms · 2026-08-03T10:53:48.279590+00:00 · methodology

0 comments
read the original abstract

In this paper, we propose \textit{aggregated vector consensus}, a new vector consensus primitive designed for asynchronous networks. The primitive achieves agreement by outputting a vector of values aggregated from independent process inputs. We then introduce \textsc{Juno}, an asynchronous common subset (ACS) protocol that fully implements our aggregated vector consensus to attain optimal $\mathcal{O}(n^2)$ message complexity. We further implement and evaluate \textsc{Juno} in comparison with the legacy HoneyBadgerBFT and the state-of-the-art Dory. Experiment results demonstrate its efficacy and efficiency. Our protocol demonstrates an average throughput performance improvement of 93\% compared with HoneyBadgerBFT and a 47\% improvement compared with Dory. Notably, our study makes significant progress in addressing the gap in applying vector consensus protocol in fully asynchronous networks.

Figures

Figures reproduced from arXiv: 2607.29244 by Jiangshan Yu, Joseph K. Liu, Liangrong Zhao, Qin Wang.

Figure 1
Figure 1. Figure 1: Overall structure of JUNO. Design-①: Obtaining a linear broadcast instance. There are n parallel broadcast instances, with each process serving as the sender (referred to as the primary from a consensus view) of an instance. In each instance, the primary initiates a transaction by broadcasting a Propose message. Processes receiving messages respond with Endorse after ver￾ification. Once a threshold of ENDO… view at source ↗
Figure 3
Figure 3. Figure 3: An example of the proposed provable broadcast. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 2
Figure 2. Figure 2: Our agreement protocol with aggregated vector [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Performance evaluation. Latency analysis (see Fig.4b&Fig.4c). JUNO maintains an 9 [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

38 extracted references

  1. [1]

    Practical Byzantine fault tolerance

    Miguel Castro, Barbara Liskov, et al. Practical Byzantine fault tolerance. InUSENIX Symposium on Operating Systems Design and Implementa- tion (OSDI), volume 99, pages 173–186, 1999

    1999

  2. [2]

    Recent progress on BFT in the era of blockchains.National Science Review, 9(10):nwac132, 2022

    Sisi Duan and Haibin Zhang. Recent progress on BFT in the era of blockchains.National Science Review, 9(10):nwac132, 2022

    2022

  3. [3]

    Muteness detectors for consensus with byzantine processes

    Assia Doudou and André Schiper. Muteness detectors for consensus with byzantine processes. InProceedings of the seventeenth annual ACM Symposium on Principles of Distributed Computing (PODC), page 315, 1998

    1998

  4. [4]

    Solving vector consensus with a wormhole.IEEE Transactions on Parallel and Distributed Systems (TPDS), 16(12):1120–1131, 2005

    Nuno Ferreira Neves, Miguel Correia, and Paulo Verissimo. Solving vector consensus with a wormhole.IEEE Transactions on Parallel and Distributed Systems (TPDS), 16(12):1120–1131, 2005

    2005

  5. [5]

    Anonymity preserving Byzantine vector consensus

    Christian Cachin, Daniel Collins, Tyler Crain, and Vincent Gramoli. Anonymity preserving Byzantine vector consensus. InEuropean Sym- posium on Research in Computer Security (ESORICS), pages 133–152. Springer, 2020

    2020

  6. [6]

    From consensus to atomic broadcast: Time-free byzantine-resistant protocols without signatures.The Computer Journal, 49(1):82–96, 2006

    Miguel Correia, Nuno Ferreira Neves, and Paulo Veríssimo. From consensus to atomic broadcast: Time-free byzantine-resistant protocols without signatures.The Computer Journal, 49(1):82–96, 2006

    2006

  7. [7]

    RITAS: Services for randomized intrusion tolerance.IEEE Transactions on Dependable and Secure Computing (TDSC), 8(1):122– 136, 2008

    Henrique Moniz, Nuno Ferreria Neves, Miguel Correia, and Paulo Verissimo. RITAS: Services for randomized intrusion tolerance.IEEE Transactions on Dependable and Secure Computing (TDSC), 8(1):122– 136, 2008. 10

    2008

  8. [8]

    The honey badger of BFT protocols

    Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of BFT protocols. InACM SIGSAC Conference on Computer and Communications Security (CCS), pages 31–42, 2016

    2016

  9. [9]

    Asynchronous secure computations with optimal resilience

    Michael Ben-Or, Boaz Kelmer, and Tal Rabin. Asynchronous secure computations with optimal resilience. InACM symposium on Principles Of Distributed Computing (PODC), pages 183–192, 1994

    1994

  10. [10]

    Secure and efficient asynchronous broadcast protocols

    Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. Secure and efficient asynchronous broadcast protocols. InAnnual Inter- national Cryptology Conference (CRYPTO), pages 524–541. Springer, 2001

    2001

  11. [11]

    Dumbo: Faster asynchronous BFT protocols

    Bingyong Guo, Zhenliang Lu, Qiang Tang, Jing Xu, and Zhenfeng Zhang. Dumbo: Faster asynchronous BFT protocols. InACM SIGSAC Conference on Computer and Communications Security (CCS), pages 803–818, 2020

    2020

  12. [12]

    BEAT: Asynchronous BFT made practical

    Sisi Duan, Michael K Reiter, and Haibin Zhang. BEAT: Asynchronous BFT made practical. InACM SIGSAC Conference on Computer and Communications Security (CCS), pages 2028–2041, 2018

    2028

  13. [13]

    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. InACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1187–1201, 2022

    2022

  14. [14]

    PACE: Fully parallelizable BFT from reproposable Byzantine agreement.ACM SIGSAC Conference on Com- puter and Communications Security (CCS), 2022

    Haibin Zhang and Sisi Duan. PACE: Fully parallelizable BFT from reproposable Byzantine agreement.ACM SIGSAC Conference on Com- puter and Communications Security (CCS), 2022

    2022

  15. [15]

    EPIC: Efficient asynchronous BFT with adaptive security

    Chao Liu, Sisi Duan, and Haibin Zhang. EPIC: Efficient asynchronous BFT with adaptive security. InIEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 437–451. IEEE, 2020

    2020

  16. [16]

    Dumbo- MVBA: Optimal multi-valued validated asynchronous Byzantine agree- ment, revisited

    Yuan Lu, Zhenliang Lu, Qiang Tang, and Guiling Wang. Dumbo- MVBA: Optimal multi-valued validated asynchronous Byzantine agree- ment, revisited. InProceedings of the Symposium on Principles of Distributed Computing (PODC), pages 129–138, 2020

    2020

  17. [17]

    Speeding Dumbo: Pushing asynchronous BFT closer to practice.Network and Distributed System Security (NDSS), 2022

    Bingyong Guo, Yuan Lu, Zhenliang Lu, Qiang Tang, Jing Xu, and Zhenfeng Zhang. Speeding Dumbo: Pushing asynchronous BFT closer to practice.Network and Distributed System Security (NDSS), 2022

    2022

  18. [18]

    FIN: Practical signature- free asynchronous common subset in constant time

    Sisi Duan, Xin Wang, and Haibin Zhang. FIN: Practical signature- free asynchronous common subset in constant time. InACM SIGSAC Conference on Computer and Communications Security (CCS), 2023

    2023

  19. [19]

    Asymptoti- cally optimal validated asynchronous byzantine agreement

    Ittai Abraham, Dahlia Malkhi, and Alexander Spiegelman. Asymptoti- cally optimal validated asynchronous byzantine agreement. InProceed- ings of the ACM Symposium on Principles of Distributed Computing (PODC), pages 337–346, 2019

    2019

  20. [20]

    Dory: Faster asynchronous BFT with re- duced communication for permissioned blockchains.Cryptology ePrint Archive, 2022

    Zongyang Zhang, You Zhou, Sisi Duan, Haibin Zhang, Bin Hu, Licheng Wang, and Jianwei Liu. Dory: Faster asynchronous BFT with re- duced communication for permissioned blockchains.Cryptology ePrint Archive, 2022

    2022

  21. [21]

    Introduction to reliable and secure distributed programming

    Christian Cachin, Rachid Guerraoui, and Luís Rodrigues. Introduction to reliable and secure distributed programming. InSpringer Science & Business Media, 2011

    2011

  22. [22]

    Signature- free asynchronous Byzantine consensus with t< n/3 and o(n2) messages

    Achour Mostéfaoui, Hamouma Moumen, and Michel Raynal. Signature- free asynchronous Byzantine consensus with t< n/3 and o(n2) messages. InACM Symposium on Principles of Distributed Computing (PODC), pages 2–9, 2014

    2014

  23. [23]

    Hybrids on steroids: SGX-based high-performance BFT

    Johannes Behl, Tobias Distler, and Rüdiger Kapitza. Hybrids on steroids: SGX-based high-performance BFT. InProceedings of the European Conference on Computer Systems (EuroSys), pages 222–237, 2017

    2017

  24. [24]

    HoneyBadgerBFT Github

    Bellemare Sylvain, Miller Andrew, dantengsky, and Schroeder Brian. HoneyBadgerBFT Github. InRetrived in https:// github.com/ initc3/ HoneyBadgerBFT-Python/, 2023

    2023

  25. [25]

    ResilientDB Github

    cjcchen et al. ResilientDB Github. InRetrived in https:// github.com/ resilientdb/ resilientdb/ tree/ resilientdb-legacy-eurosys23, 2023

    2023

  26. [26]

    Asynchronous secure computation

    Michael Ben-Or, Ran Canetti, and Oded Goldreich. Asynchronous secure computation. InACM Symposium on Theory of Computing (STOC), pages 52–61, 1993

    1993

  27. [27]

    Asynchronous distributed key generation for computationally-secure randomness, consensus, and threshold signatures

    Eleftherios Kokoris Kogias, Dahlia Malkhi, and Alexander Spiegelman. Asynchronous distributed key generation for computationally-secure randomness, consensus, and threshold signatures. InProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 1751–1767, 2020

    2020

  28. [28]

    Practical asynchronous distributed key generation

    Sourav Das, Thomas Yurek, Zhuolun Xiang, Andrew Miller, Lefteris Kokoris-Kogias, and Ling Ren. Practical asynchronous distributed key generation. InIEEE Symposium on Security and Privacy (SP), pages 2518–2534. IEEE, 2022

    2022

  29. [29]

    Practical asynchronous high-threshold distributed key generation and distributed polynomial sampling

    Sourav Das, Zhuolun Xiang, Lefteris Kokoris-Kogias, and Ling Ren. Practical asynchronous high-threshold distributed key generation and distributed polynomial sampling. InUSENIX Security Symposium (USENIX Security), pages 5359–5376, 2023

    2023

  30. [30]

    On communication-efficient asynchronous MPC with adaptive security

    Annick Chopard, Martin Hirt, and Chen-Da Liu-Zhang. On communication-efficient asynchronous MPC with adaptive security. In International Conference on Theory of Cryptography (TCC), pages 35–

  31. [31]

    Honeybadgermpc and asynchromix: Practical asynchronous mpc and its application to anonymous commu- nication

    Donghang Lu, Thomas Yurek, Samarth Kulshreshtha, Rahul Govind, Aniket Kate, and Andrew Miller. Honeybadgermpc and asynchromix: Practical asynchronous mpc and its application to anonymous commu- nication. InProceedings of the ACM SIGSAC Conference on Computer and Communications Security (CCS), pages 887–903, 2019

    2019

  32. [32]

    WaterBear: Practical asynchronous BFT matching security guarantees of partially synchronous BFT

    Haibin Zhang, Sisi Duan, Boxin Zhao, and Liehuang Zhu. WaterBear: Practical asynchronous BFT matching security guarantees of partially synchronous BFT. InUSENIX Security Symposium (USENIX Security), pages 5341–5357, 2023

    2023

  33. [33]

    Asynchronous Byzantine agreement protocols.Infor- mation and Computation, 75(2):130–143, 1987

    Gabriel Bracha. Asynchronous Byzantine agreement protocols.Infor- mation and Computation, 75(2):130–143, 1987

    1987

  34. [34]

    Frugal Byzantine computing

    Marcos K Aguilera, Naama Ben-David, Rachid Guerraoui, Dalia Papuc, Athanasios Xygkis, and Igor Zablotchi. Frugal Byzantine computing. International Symposium on Distributed Computing (DISC), 2021

    2021

  35. [35]

    HotStuff: BFT consensus with linearity and respon- siveness

    Maofan Yin, Dahlia Malkhi, Michael K Reiter, Guy Golan Gueta, and Ittai Abraham. HotStuff: BFT consensus with linearity and respon- siveness. InACM Symposium on Principles of Distributed Computing (PODC), pages 347–356, 2019

    2019

  36. [36]

    Communication-efficient BFT using small trusted hardware to tolerate minority corruption

    Sravya Yandamuri, Ittai Abraham, Kartik Nayak, and Michael K Reiter. Communication-efficient BFT using small trusted hardware to tolerate minority corruption. InInternational Conference on Principles of Distributed Systems (OPODIS). Schloss-Dagstuhl-Leibniz Zentrum für Informatik, 2023

    2023

  37. [37]

    DAMYSUS: streamlined BFT consensus leveraging trusted components

    Jérémie Decouchant, David Kozhaya, Vincent Rahli, and Jiangshan Yu. DAMYSUS: streamlined BFT consensus leveraging trusted components. InProceedings of the European Conference on Computer Systems (EuroSys), pages 1–16, 2022

    2022

  38. [38]

    Byzantine vector consensus in complete graphs

    Nitin H Vaidya and Vijay K Garg. Byzantine vector consensus in complete graphs. InProceedings of the 2013 ACM symposium on Principles of distributed computing, pages 65–73, 2013. 11

    2013