Pith. sign in

REVIEW 4 major objections 5 minor 24 references

Ocior: Ultra-Fast Asynchronous Leaderless Consensus with Two-Round Finality, Linear Overhead, and Adaptive Security

T0 review · 4 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read Asynchronous BFT finalizes transactions in two rounds with linear overhead

desk verdict Genuine LTS novelty, but the O(n) computation claim is impossible at the paper's own parameters and adaptive security is deferred—so the headline results don't stand. read the letter →

arxiv 2509.01118 v2 pith:QAVY6OFS submitted 2025-09-01 cs.DC

Jinyuan Chen This is my paper · ORCID
classification cs.DC
keywords asynchronousByzantinefaulttoleranceleaderlessconsensusadaptivesecuritythresholdsignaturelayeredAttestedProofofSealcommunicationcomplexityblockchainfinality
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

Ocior sets out to close the gap between asynchronous Byzantine fault-tolerant consensus and latency-sensitive blockchains. It claims a leaderless protocol that can irrevocably finalize a two-party transaction after two one-way message rounds even under arbitrary network delays and an adaptive adversary controlling up to t of n >= 3t+1 nodes, while spending only O(n) expected messages and O(n) best-case computation per transaction. The load-bearing mechanism is a new threshold-signature design, OciorBLSts, which layers partial signatures in a tree so aggregation can happen online and in linear time whenever the good case of signature collection occurs. The paper also introduces short Attested Proofs of Seal so light clients can verify finality without running a full node. If correct, this gives asynchronous finality at costs previously attainable only in partially synchronous or leader-based settings.

What carries the argument

OciorBLSts is the central object: an adaptively secure non-interactive threshold signature formed by composing one conventional threshold signature (TS) with one or more Layered Threshold Signatures (LTS). In LTS, n = n_1 * ... * n_L signers are arranged as leaves of a tree, with group thresholds k_l whose product is at least k; any k_l valid signatures in a group produce a parent partial signature, and after L levels the final signature emerges. This allows instantaneous, O(n) aggregation in the good case, with the ordinary TS scheme as a fallback at O(n log^2 n) worst-case cost. The consensus layer uses these signatures to seal transactions on n parallel chains and to form Type I and Type

What would settle it

Fix n=1400, t=466, L=3 with group sizes (14,10,10) and thresholds (13,9,8). Compute or simulate the probability that a random placement of 466 faulty nodes puts at most 2 faulty nodes in every one of the 140 leaf groups of size 10. If that probability is negligible rather than very high, the central good-case assumption fails. Alternatively, run Ocior with an adaptive adversary and measure how often a two-round APS is actually produced before the fallback path completes.

Watch

Extended reading notes

Core claim

Ocior claims that asynchronous BFT consensus need not sacrifice latency, throughput, or adaptive security. The protocol runs n parallel chains, one proposed by each node, and attaches threshold signatures to transactions; finality is a short signature called an APS. A legitimate two-party transaction proposed by an honest node can receive an APS after two asynchronous one-way rounds for any n >= 3t+1, and no conflicting transaction can later receive a valid APS because each signature requires votes from k = ceil((n+t+1)/2) nodes. The expected communication per transaction is O(n), and computation is O(n) in the good case or O(n log^2 n) in the worst case. The enabling primitive, OciorBLSts,

Load-bearing premise

The adaptive-security and good-case guarantees rest on the key-generation protocol OciorADKG, whose detailed proofs are not in this paper, and on the assumption that a favorable good case of signature collection becomes overwhelmingly likely after O(t) epochs; if either premise fails, the headline adaptive-security and O(n)-computation claims collapse.

Editorial extensions

If this is right

  • If Ocior is correct, a client sending a two-party transfer can receive a short, independently verifiable proof of finality after two one-way network delays, without waiting for ledger ordering.
  • Expected per-transaction message complexity of O(n) would remove batching as a prerequisite for throughput, letting a consensus node handle individual transactions concurrently.
  • The absence of a designated leader means no single node can be targeted to stall the system; an adaptive adversary is tolerated as long as the total corruption budget stays below t with n >= 3t+1.
  • The Type II APS path guarantees eventual dissemination of any transaction with acceptance weight 3, bridging fast client-visible finality to full system-wide acceptance.
  • The adaptive security of the whole protocol rests on OciorADKG; the paper explicitly commits to proving that in an extended version.

Reading between the lines

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

  • The paper leaves implicit that the good case may be rare at its own scale: with n=1400, t=466, L=3, and group thresholds (k1,k2,k3)=(13,9,8), every one of the 140 leaf groups of size 10 must contain at most 2 faulty nodes before LTS can finish, so the claimed O(n) good-case aggregation may occur with very low probability under random placement of the faulty nodes.
  • Two-round finality is a good-case latency bound; in adversarial executions the fallback paths (four rounds, HMDM multicasts, or broadcasting of locked signatures) may dominate, so end-to-end latency can be much larger in practice.
  • The layered-signature idea could plausibly be reused to certify arbitrary values, not just asset transfers, but the paper's safety argument is tied to parent-child transaction legitimacy and double-spending checks, so such reuse would need a new conflict model.
  • A direct stress test is to run Ocior under an adaptive scheduler that targets proposer nodes and measure how often the two-round APS path completes relative to the fallback paths; the paper does not report such an evaluation.
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 / 5 minor

Summary. The paper proposes Ocior, an asynchronous leaderless BFT consensus protocol claiming optimal resilience (n >= 3t+1 against an adaptive adversary), O(n) expected communication per transaction, O(n) best-case / O(n log^2 n) worst-case computation, and two-round good-case finality for two-party transactions. The design uses n parallel proposal chains, per-transaction consensus instances, short "Attested Proof of Seal" certificates, and a new threshold-signature scheme OciorBLSts based on Layered Threshold Signatures (LTS). Section VI introduces OciorADKG to support adaptive security. The paper gives theorems for safety, liveness, round complexity, communication complexity, and computation complexity, with section-level proofs and pseudocode.

Significance. If the results were established, this would be a substantial advance: two-round asynchronous finality at optimal resilience with linear communication would be stronger than existing asynchronous BFT protocols. The manuscript is detailed and the basic quorum-intersection safety argument (Theorem 1) is internally consistent for same-parent conflicts; the two-round good-case latency is plausible by construction under well-behaved scheduling; and the algebraic identity in Appendix A is proved correctly. However, the headline good-case computation claim is contradicted by the paper's own LTS parameters, and the adaptive-security claim is explicitly deferred to an extended version. The central contributions are therefore not established in the submitted manuscript.

major comments (4)
  1. [Section III.C, Definition 27, Fig. 2] The LTS 'good case' is impossible at the paper's own parameters (n=1400, t=466, L=3, n1=14, k1=13, n2=10, k2=9, n3=10, k3=8). A valid final signature requires 13 valid Layer-1 partial signatures, each requiring 9 valid Layer-2 parents, each requiring 8 valid Layer-3 leaves in a 10-node group. Hence 117 distinct Layer-3 groups must each contain at most n3-k3=2 faulty nodes. With t=466, 117 groups can absorb at most 234 faulty nodes, leaving at least 232 faulty nodes for the remaining 23 groups, whose total capacity is 230. Therefore the good case has probability zero for every corruption set of size 466. This directly contradicts the Section III.C assertion that the probability of a good case 'becomes very high' after O(t) epochs, and it invalidates Theorem 7's O(n) best-case computation per transaction at optimal resilience.
  2. [Section VI] The adaptive-security guarantee, featured in the title and abstract, has no proof in this manuscript. Section VI explicitly states: 'we focus on describing the proposed OciorADKG protocol and the introduced primitives, while leaving detailed proofs to the extended version of this paper.' The construction depends on the new OciorSHPC and OciorASHVSS primitives and on the author's own APVA protocol [23], none of which is established here. Since the consensus theorems assume adaptively secure threshold signatures, the central security claim is unsupported.
  3. [Section IV.B, Algorithm 4, Algorithm 5] There is a load-bearing inconsistency about the vote threshold for finality. The basic protocol description says a proposer generates a threshold signature after receiving k=ceil((n+t+1)/2) valid partial signatures, but Algorithm 4 (line 12) and Algorithm 5 (line 128) wait for |A_ts[ID]| = n-t before running TS.Combine. For n > 3t+1, k < n-t, so the two-round finality claim in Theorem 5 is not tied to a single, well-defined combination event. The paper should specify exactly which condition produces the APS and prove the good-case latency for that condition.
  4. [Section V, Theorem 6] The proof of O(n) expected communication relies on the unproven assertion that 'each honest node selects a transaction different from those proposed by other honest nodes with constant probability' and does not rigorously account for duplicate proposals, re-proposals, and APS propagation in the per-transaction amortization. Since O(n) communication is one of the paper's headline optimality claims, this needs a precise argument with explicit parameters and adversarial cases.
minor comments (5)
  1. [Algorithm 2 caption] 'information theocratic secure' should read 'information-theoretically secure'.
  2. [Section III.C] The statement that the adversary 'becomes effectively static after O(t) epochs' is informal and not proved. An adaptive adversary can keep corrupting different nodes over time; the security argument must handle all corruption patterns, not only those that exhaust the budget.
  3. [Lemma 2 proof] The inequality '>= (3t+1+t+1)/2 - 2t > 1' is false at n=3t+1, where the value is exactly 1. The lemma may still be repairable, but the calculation should be corrected to '>= 1'.
  4. [Definitions 19, 20, 28, 29] The text contains typos such as 'f alse' for 'false'. Also, the security games would benefit from explicitly stating that partial signatures from corrupted nodes count toward the adversary's 'obtained' set, which is implicitly done but should be formalized.
  5. [Section I, Table I] The table lists Ocior's good-case computation as O(n), but this is exactly the claim contradicted by the LTS parameter analysis; the table should be reconsidered after the LTS good-case issue is resolved.

Circularity Check

2 steps flagged · score 6.0 of 10

Load-bearing adaptive-security and liveness claims are carried by the author's own unpublished/self-cited OciorADKG/APVA/COOL chain, with ADKG proofs explicitly deferred; the O(n) good-case LTS claim is also asserted via a 'good case' that conflicts with the paper's own parameters.

  1. self citation load bearing [Section VI, Definition 34 and OciorADKG overview (Algorithm 9)]
    "We use the efficient APVA protocol proposed in [23], which achieves APVA consensus with an expected communication complexity of O(n^3 log n) bits and an expected round complexity of O(1) rounds. ... In this work, we focus on describing the proposed OciorADKG protocol and the introduced primitives, while leaving detailed proofs to the extended version of this paper."

    OciorADKG generates all TS and LTS key shares used by Ocior, so the central adaptive-security claim (n>=3t+1) rests on it. The paper gives no proof here—the security proof is deferred to a non-existent 'extended version'—and the APVA protocol it invokes, [23], is the same author's separate arXiv preprint. Thus the adaptive-security premise is not derived in this manuscript; it is imported from an unverified self-citation chain. The advertised adaptively secure O(n)-overhead consensus therefore reduces, at this load-bearing step, to the correctness of the author's own unpublished prior work.

  2. self citation load bearing [Section II, Definition 13 (HMDM), Algorithm 2]
    "The OciorHMDMit protocol is derived from the COOL protocol [15]–[17] and is information-theoretically secure and error-free; that is, it guarantees the required properties in all executions without relying on cryptographic assumptions."

    OciorHMDMit is used to multicast locked-chain signatures and contents to all nodes (Algorithm 5, Lines 139-145), which is needed for liveness and for the amortized O(n) communication claimed in Theorem 6. The cited COOL sources [15]-[17] are all by the same author and are not proved or reproduced in this paper. The correctness of a core liveness/communication building block is therefore asserted by reference to the author's own prior work rather than derived in the present derivation chain.

full rationale

The protocol's basic consensus skeleton has independent content: the two-round Propose/Vote flow and the quorum-intersection argument (k=ceil((n+t+1)/2)) would prevent conflicting APSs if a secure threshold signature scheme were supplied, and that part is not circular. However, the headline guarantees go beyond this skeleton. Adaptive security depends on OciorADKG, whose proofs are explicitly deferred and whose APVA building block is the same author's arXiv preprint [23]; the HMDM used for liveness and communication is likewise 'derived from the COOL protocol [15]–[17]', all by the same author. None of these is machine-checked, code-reproduced, or independently verified in the manuscript. In addition, the best-case O(n) computation rests on the LTS 'good case' (Definition 27), whose claimed high probability after O(t) epochs is not proved; at the paper's own illustrative parameters (n=1400, t=466, n3=10, k3=8) a good case would require 117 leaf groups with at most 2 faulty nodes each, but 117*2 + 23*10 = 464 < 466, so no corruption set of size 466 can satisfy it. That is a consistency problem rather than a circularity, but it reinforces that the linear-computation claim is not established by the derivation. Weighing these together, the central security and complexity claims are partially carried by a self-citation chain with deferred proofs, giving a circularity score of 6 rather than a clean self-contained derivation.

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

The central claims rest on (i) building blocks from the author's own unrefereed work: OciorHMDM_it is 'derived from the COOL protocol [15]-[17]' and OciorADKG invokes 'the efficient APVA protocol proposed in [23]', none machine-checked or reproduced here; (ii) explicitly deferred proofs: Section VI leaves ADKG security to 'the extended version of this paper', and the TS/LTS/SHPC security properties (Definitions 19, 20, 28-31) are asserted without proof; and (iii) two ad hoc probabilistic assumptions: the constant-probability distinct-selection guarantee in Theorem 6's proof, and the claim that LTS good cases become highly probable after O(t) epochs, the latter contradicted by the paper's own example parameters. The LTS aggregation parameters (L, n_l, k_l, m_max, h_dm, e_out, Delta_delay, m_txself, m_txpo) are hand-chosen and determine whether the claimed O(n) computation and O(n) amortized communication actually materialize.

free parameters (3)
  • LTS layer parameters (L, {n_l}, {k_l}) = e.g., L=3, n=(14,10,10), k=(13,9,8) for n=1400
    Chosen by hand; they define the LTS 'good case' and determine how unlikely the O(n) aggregation path is (far below 10^-40 at t=n/3).
  • Epoch size m_max = > n^2 (set as m_max > n2)
    Needed to amortize ADKG and epoch-transition costs so per-transaction communication stays O(n); the amortization claim is asserted, not proven.
  • Multicast interval h_dm, timeout e_out, selection odds m_txself/m_txpo, delay Delta_delay = h_dm=ceil(n log n), e_out=n, m_txself=2, m_txpo=ceil(n/10), Delta_delay preset
    Preset parameters that make the HMDM and selection-probability analysis work in the complexity proofs; the O(n) per-transaction claim depends on their interplay.
assumptions (8)
  • domain assumption Correctness and validity of the HMDM protocols (Algorithms 1 and 2), derived from COOL [15]-[17]
    Invoked in Lemma 4/5 and Theorem 6 for APS dissemination and communication amortization; no proof is given in this paper.
  • domain assumption Correctness, termination, and O(n^3 log n) complexity of the APVA protocol of [23]
    Invoked in the OciorADKG selection phase; [23] is the author's own unrefereed arXiv preprint, not reproduced here.
  • domain assumption Adaptive security of OciorADKG under the algebraic group model and the one-more discrete logarithm assumption
    Explicitly deferred: Section VI, 'leaving detailed proofs to the extended version of this paper'.
  • domain assumption Robustness and unforgeability of OciorBLSts (Definitions 19, 20, 28, 29)
    The paper defines these properties but gives no reduction or proof for the TS/LTS schemes.
  • ad hoc to paper 'Each honest node selects a transaction different from those proposed by other honest nodes with constant probability' (Theorem 6 proof)
    A workload-dependent assumption presented as a guarantee; the O(n) expected communication claim depends on it.
  • ad hoc to paper 'The adversary becomes effectively static after O(t) epochs' so LTS good cases 'become very high' probability (Section III.C)
    Heuristic claim about the adaptive adversary and LTS group distribution; no formal statement, and contradicted by the paper's own example parameters.
  • standard math Random-oracle model for H and H_z; algebraic group model; one-more discrete logarithm hardness
    Standard cryptographic assumptions stated in Sections III and VI.
  • domain assumption Strict secrecy of SHPC and completeness of OciorASHVSS
    New primitive introduced in Section VI; the properties are asserted with proofs deferred.
invented entities (3)
  • Attested Proof of Seal (APS)
    purpose: Short cryptographic proof of transaction finality for lightweight clients
    A protocol artifact (threshold signature plus content) with no falsifiable handle outside the protocol; its validity is internal.
  • Layered Threshold Signatures (LTS)
    purpose: O(n) good-case signature aggregation through fixed small groups
    New primitive whose security is asserted in Definitions 28-29 without proof; no external benchmark.
  • Strictly-Hiding Polynomial Commitment (SHPC)
    purpose: Hides secrets in ASHVSS/ADKG until a specified timing condition
    New primitive in Section VI, proof of strict secrecy deferred.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Ocior: Ultra-Fast Asynchronous Leaderless Consensus with Two-Round Finality, Linear Overhead, and Adaptive Security." pith.science (2026). https://pith.science/paper/QAVY6OFS

@misc{pith2026250901118,
  author       = {Pith},
  title        = {Pith review of: Ocior: Ultra-Fast Asynchronous Leaderless Consensus with Two-Round Finality, Linear Overhead, and Adaptive Security},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QAVY6OFS}},
  note         = {Machine review of arXiv:2509.01118}
}
abstract

In this work, we propose Ocior, a practical asynchronous Byzantine fault-tolerant (BFT) consensus protocol that achieves the optimal performance in resilience, communication, computation, and round complexity. Unlike traditional BFT consensus protocols, Ocior processes incoming transactions individually and concurrently using parallel instances of consensus. While leader-based consensus protocols rely on a designated leader to propose transactions, Ocior is a leaderless consensus protocol that guarantees stable liveness. Ocior achieves: 1) Optimal resilience: Ocior tolerates up to $t$ faulty nodes controlled by an adaptive adversary, for $n\geq 3t+1$. 2) Optimal communication complexity: The total expected communication per transaction is $O(n)$. 3) Optimal (or near-optimal) computation complexity: The total computation per transaction is $O(n)$ in the best case, or $O(n \log^2 n)$ in the worst case. 4) Optimal round complexity: A legitimate two-party transaction can be finalized with a good-case latency of two asynchronous rounds, for any $n\geq 3t+1$. The good case in terms of latency refers to the scenario where the transaction is proposed by any (not necessarily designated) honest node. A two-party transaction involves the transfer of digital assets from one user (or group of users) to one or more recipients. To support efficient consensus, we introduce a novel non-interactive threshold signature (TS) scheme called OciorBLSts. It offers fast signature aggregation, and is adaptively secure. OciorBLSts achieves a computation complexity of signature aggregation of only $O(n)$ in the good cases. Moreover, OciorBLSts supports the property of Instantaneous TS Aggregation. This enables real-time aggregation of partial signatures as they arrive, reducing waiting time and improving responsiveness.

Figures

Figures reproduced from arXiv: 2509.01118 by the authors.

Figure 1
Figure 1. The network architecture of Ocior, consisting of consensus nodes (servers), remote procedure call ( [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. A tree structure of partial signatures of the proposed [PITH_FULL_IMAGE:figures/full_fig_p012_2.png] view at source ↗
Figure 3
Figure 3. The description of the algorithms used in the proposed [PITH_FULL_IMAGE:figures/full_fig_p017_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The description of the parallel chains in Ocior. [PITH_FULL_IMAGE:figures/full_fig_p019_4.png]
Figure 5
Figure 5. Figure 5: The epoch structure of Ocior, where different nodes may enter a new epoch at different times due to the asynchronous nature of the network. During Epoch e, for e ≥ 1, the ADKG[e + 1] scheme is executed to generate keys for Epoch e + 1, with ADKG[e + 1] running in paral…
Figure 6
Figure 6. Figure 6: Description of the official parent signature and virtual parent signature in [PITH_FULL_IMAGE:figures/full_fig_p020_6.png]
Figure 7
Figure 7. Figure 7: The two-round consensus of basic Ocior for two-party transactions. In this description, the transaction [PITH_FULL_IMAGE:figures/full_fig_p022_7.png]
Figure 8
Figure 8. Figure 8: The structure of chained Ocior, shown here for Chain i with i ∈ [n]. The other chains follow a similar Propose-Vote structure. C. Chained Ocior The chained Ocior is described in [PITH_FULL_IMAGE:figures/full_fig_p023_8.png]
Figure 9
Figure 9. Figure 9: The description of the proposed strictly-hiding polynomial commitment scheme [PITH_FULL_IMAGE:figures/full_fig_p044_9.png]
Figure 10
Figure 10. Figure 10: A block diagram of the proposed OciorADKG protocol with an identifier ID, where Aones := {j ∈ [n] | a ⋆ [j] = 1} and Bones is obtained from Aones by removing the indices of nodes that did not honestly share their secrets in the OciorASHVSS phase. In the description, w…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 23 canonical work pages

  1. [23]

    OciorABA: Improved Error-Free Asynchronous Byzantine Agreement via Partial Vector Agreement

    J. Chen, “OciorABA: Improved error-free asynchronous Byzantine agreement via partial vector agreement,” Jan. 2025, available on ArXiv: https://arxiv.org/abs/2501.11788

    work page Pith review arXiv 2025

  2. [1]

    CoinMarketCap, https://coinmarketcap.com

    work page

  3. [2]

    Solana: A new architecture for a high performance blockchain,

    A. Yakovenko, “Solana: A new architecture for a high performance blockchain,” https://solana.com/solana-whitepaper.pdf, 2018

    work page 2018

  4. [3]

    Hotstuff: BFT consensus with linearity and responsiveness,

    M. Yin, D. Malkhi, M. Reiter, G. Gueta, and I. Abraham, “Hotstuff: BFT consensus with linearity and responsiveness,” inProceedings of the ACM Symposium on Principles of Distributed Computing (PODC), Jul. 2019, pp. 347–356

    work page 2019

  5. [4]

    Practical Byzantine fault tolerance,

    M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” inProceedings of the third symposium on Operating systems design and implementation, vol. 99, no. 1999, Feb. 1999, pp. 173–186

    work page 1999

  6. [5]

    Hydrangea: Optimistic two-round partial synchrony,

    N. Shrestha, A. Kate, and K. Nayak, “Hydrangea: Optimistic two-round partial synchrony,” Cryptology ePrint Archive, Paper 2025/1112, Jul. 2025. [Online]. Available: https://eprint.iacr.org/2025/1112

    work page 2025

  7. [6]

    The honey badger of BFT protocols,

    A. Miller, Y . Xia, K. Croman, E. Shi, and D. Song, “The honey badger of BFT protocols,” in2016 ACM SIGSAC Conference on Computer and Communications Security, Oct. 2016

    work page 2016

  8. [7]

    EPIC: Efficient asynchronous BFT with adaptive security,

    C. Liu, S. Duan, and H. Zhang, “EPIC: Efficient asynchronous BFT with adaptive security,” inInternational Conference on Dependable Systems and Networks, 2020, pp. 437–451

    work page 2020

Show all 24 references
  1. [8]

    Ethereum consensus specifications,

    Ethereum Foundation, “Ethereum consensus specifications,” https://github.com/ethereum/consensus-specs, 2022. [Online]. Available: https://github.com/ethereum/consensus-specs

    2022

  2. [9]

    Scalable and probabilistic leaderless BFT consensus through metastability,

    T. Rocket, M. Yin, K. Sekniqi, R. van Renesse, and E. G. Sirer, “Scalable and probabilistic leaderless BFT consensus through metastability,” Aug. 2020, available on ArXiv: https://arxiv.org/abs/1906.08936

    2020 arXiv

  3. [10]

    Towards scalable threshold cryptosystems,

    A. Tomescu, R. Chen, Y . Zheng, I. Abraham, B. Pinkas, G. Golan-Gueta, and S. Devadas, “Towards scalable threshold cryptosystems,” inIEEE Symposium on Security and Privacy (SP), May 2020, pp. 877–893

    2020

  4. [11]

    Zyzzyva: Speculative Byzantine fault tolerance,

    R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, “Zyzzyva: Speculative Byzantine fault tolerance,”ACM Trans. Comput. Syst., vol. 27, no. 4, pp. 1–39, Jan. 2010

    2010

  5. [12]

    SBFT: A scalable and decentralized trust infrastructure,

    G. Gueta, I. Abraham, S. Grossman, D. Malkhi, B. Pinkas, M. Reiter, D. Seredinschi, O. Tamir, and A. Tomescu, “SBFT: A scalable and decentralized trust infrastructure,” in49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), Jun. 2019

    2019

  6. [13]

    Kudzu: Fast and simple high-throughput BFT,

    V . Shoup, J. Sliwinski, and Y . V onlanthen, “Kudzu: Fast and simple high-throughput BFT,” May 2025, available on ArXiv: https://arxiv.org/abs/2505.08771

    2025

  7. [14]

    Solana websocket: Real-time blockchain data streaming,

    Solana, “Solana websocket: Real-time blockchain data streaming,” 2025. [Online]. Available: https://solana.com/docs/rpc/websocket

    2025

  8. [15]

    Fundamental limits of Byzantine agreement,

    J. Chen, “Fundamental limits of Byzantine agreement,” 2020, available on ArXiv: https://arxiv.org/pdf/2009.10965.pdf

    2020 arXiv

  9. [16]

    Optimal error-free multi-valued Byzantine agreement,

    ——, “Optimal error-free multi-valued Byzantine agreement,” inInternational Symposium on Distributed Computing (DISC), Oct. 2021

    2021

  10. [17]

    OciorCOOL: Faster Byzantine agreement and reliable broadcast,

    ——, “OciorCOOL: Faster Byzantine agreement and reliable broadcast,” Sep. 2024, available on ArXiv: https://arxiv.org/abs/2409.06008

    2024 arXiv

  11. [18]

    Polynomial codes over certain finite fields,

    I. Reed and G. Solomon, “Polynomial codes over certain finite fields,”Journal of the Society for Industrial and Applied Mathematics, vol. 8, no. 2, pp. 300–304, Jun. 1960

    1960

  12. [19]

    Expander codes,

    M. Sipser and D. Spielman, “Expander codes,”IEEE Trans. Inf. Theory, vol. 42, no. 6, pp. 1710–1722, Nov. 1996

    1996

  13. [20]

    Asynchronous secure computation,

    M. Ben-Or, R. Canetti, and O. Goldreich, “Asynchronous secure computation,” inProceedings of the Twenty-Fifth Annual ACM Symposium on Theory of Computing, 1993, pp. 52–61

    1993

  14. [21]

    SCRAPE: Scalable randomness attested by public entities,

    I. Cascudo and B. David, “SCRAPE: Scalable randomness attested by public entities,” inInternational Conference on Applied Cryptography and Network Security, 2017, pp. 537–556

    2017

  15. [22]

    Non-interactive distributed key generation and key resharing,

    J. Groth, “Non-interactive distributed key generation and key resharing,” Cryptology ePrint Archive, Paper 2021/339, 2021. [Online]. Available: https://eprint.iacr.org/2021/339

    2021

  16. [24]

    Asynchronous consensus without trusted setup or public-key cryptography,

    S. Das, S. Duan, S. Liu, A. Momose, L. Ren, and V . Shoup, “Asynchronous consensus without trusted setup or public-key cryptography,” in2024 ACM SIGSAC Conference on Computer and Communications Security, Dec. 2024, pp. 3242–3256

    2024

Pith tools

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