Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Orthrus: Accelerating Multi-BFT Consensus through Concurrent Partial Ordering of Transactions (Extended Version)

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

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

Pith's one-line read Orthrus claims per-instance partial ordering of payments can keep BFT safety while cutting WAN latency by up to 87%.

desk verdict Promising hybrid BFT design with a credible evaluation, but the multi-payer escrow atomicity is under-specified and the correctness proof does not close the gap. read the letter →

arxiv 2501.14732 v3 pith:WIKO2GJH submitted 2024-12-09 cs.DC cs.PF

Hanzheng Lyu , Shaokang Xie , Jianyu Niu , Ivan Beschastnikh , Yinqian Zhang , Mohammad Sadoghi , Chen Feng This is my paper · ORCID
classification cs.DCcs.PF
keywords ByzantinefaulttoleranceMulti-BFTconsensuspartialorderingglobalescrowmechanismtransactionatomicitylatencyoptimizationblockchain
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

Orthrus is a Multi-BFT consensus protocol that tries to show that most blockchain transactions, the conflict-free payments, can be confirmed under a per-instance partial order instead of waiting for a global total order. The paper argues that by assigning transactions to instances based on the payer, only decremental operations on shared accounts need ordering, while incremental operations and payments between different accounts commute. A carefully designed escrow mechanism keeps multi-payer and contract-plus-payment transactions atomic, so the relaxed ordering does not sacrifice safety or liveness. If the protocol is right, payment-heavy workloads in partially synchronous Byzantine networks can cut confirmation latency dramatically, up to 87% in the paper's WAN experiments at 128 replicas with a straggler, without weakening the system's Byzantine guarantees.

What carries the argument

The load-bearing mechanism is the combination of per-instance partial logs (plog) with a single global log (glog), coordinated by an escrow log (elog). Payment transactions that pass the escrow check are committed straight from the partial log, while contract transactions continue through the global-ordering algorithm, adopted from Ladon, so that non-commutative operations execute in a common sequence. The escrow operation temporarily applies a decrement to an owned object, records the request in elog, and either commits all requests of a transaction or undoes them, which is what lets the protocol claim atomicity across instances and claim that a payment can proceed without waiting for a related contract transaction to be globally ordered.

What would settle it

Run a two-instance experiment where a leader proposes a block whose state S omits a recently delivered block from the other instance that funds the payer's balance. If honest replicas accept and execute the payment under that stale S while another replica with the current state executes a conflicting spending transaction, the two replicas will reach different object values, directly contradicting Theorem 1. The Appendix B running example can be modified to force this by delivering tx0 on Instance 1 before Instance 0's block referencing S = {0,⊥} is proposed.

Watch

Extended reading notes

Core claim

On its own terms, the paper's central claim is that a hybrid ordering discipline suffices for Byzantine fault-tolerant state-machine replication: payment transactions can be partially ordered within each consensus instance and executed concurrently across instances, while only non-commutative contract transactions need to be merged into a global log. Orthrus partitions transactions by payer into buckets, lets each instance leader propose blocks that reference a system-state tuple S, and uses an escrow mechanism to temporarily reserve funds so that multi-payer transactions either all commit or all abort. The paper proves safety, replicas in the same state see identical object values, and liveness, every correct client transaction is eventually confirmed, and reports experiments on 8 to 128 replicas in WAN and LAN where Orthrus lowers latency by up to 87% compared with existing Multi-BFT protocols such as ISS, Mir-BFT, RCC, DQBFT, and Ladon.

Load-bearing premise

The protocol assumes that the state tuple S that each leader writes into a block is an accurate, consistent snapshot of all instances, so that every transaction pulled into that block is valid under that state; the paper does not specify how leaders discover and reference cross-instance dependencies, and if S can be stale or mutually inconsistent, the claim that replicas in the same state execute the same transactions does not follow.

Editorial extensions

If this is right

  • Payment transactions from different payers can be confirmed as soon as their own instance delivers them, without waiting for the slowest instance in the system.
  • A straggler instance no longer stalls the confirmation of unrelated payments, which is the main source of the reported latency reduction.
  • Multi-payer payment transactions remain atomic: all escrow requests succeed or all are undone, so no payer can lose funds while another payer's transfer aborts.
  • Contract transactions keep global ordering, so non-commutative operations such as assignments to shared state still produce identical outcomes on all honest replicas.
  • Throughput stays comparable to top Multi-BFT protocols in the no-straggler case, while latency improves, meaning the concurrency gain does not require sacrificing raw throughput.

Reading between the lines

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

  • If the payer-based partition is sound, the same hybrid partial/global-ordering pattern could be applied to sharded blockchains, where cross-shard transactions are the minority, to reduce cross-shard confirmation latency.
  • The escrow primitive could be reused as a general concurrency-control mechanism for any replicated state machine with commutative and non-commutative operation classes, decoupling fast-path confirmation from total order.
  • The reported 87% gain is tied to the workload mix, 46% payment transactions in the Ethereum-derived dataset; workloads with a higher payment share should see larger relative gains, and purely contract workloads should see the advantage shrink toward zero.
  • A direct testable prediction is that Orthrus's latency advantage over global-ordering Multi-BFT protocols should grow roughly with the payment-transaction fraction and with the straggler slowdown factor, since both increase the time that would otherwise be spent waiting for the global log.
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 introduces Orthrus, a Multi-BFT consensus protocol that combines partial ordering for payment transactions with global ordering for contract transactions. Transactions are partitioned into per-instance buckets by payer; each instance runs a sequenced-broadcast consensus, payment transactions are executed from partial logs as soon as they are delivered, and contract transactions are ordered globally using the Ladon dynamic global ordering algorithm. A distributed escrow mechanism is proposed to preserve atomicity for multi-payer transactions and to prevent pending contract transactions from blocking payments. The authors implement Orthrus on the ISS platform and evaluate it on AWS with up to 128 replicas in WAN and LAN settings, reporting latency reductions of up to 87% compared with existing Multi-BFT protocols when a straggler is present.

Significance. If the protocol is correct, Orthrus addresses a real performance problem in Multi-BFT systems: global ordering imposes latency even for conflict-free transactions and is severely amplified by straggler instances. The evaluation is credible and follows standard methodology, includes a real Ethereum-derived workload, compares against several relevant baselines, and makes the source code available. The paper's main conceptual contribution, using partial ordering for commutative payments while retaining global ordering for non-commutative contracts, is potentially valuable. However, the correctness argument is not yet at the level required for a systems venue: the escrow-based atomicity mechanism is under-specified in the pseudocode, and the state-snapshot mechanism that underpins the partial order is not defined precisely enough to support the safety lemmas.

major comments (4)
  1. [Section V-C, Algorithm 1 lines 20-30; Lemma 5] The atomicity argument for multi-payer payment transactions is not supported by the pseudocode. Each occurrence of a transaction in a different plog is processed independently: the replica escrows the local payer's decremental object, checks allEscrowed(tx) against its local elog, and then either commits, aborts, or does nothing. There is no per-transaction state machine, no cross-instance commit protocol, and no rule stating whether an occurrence that is not yet all-escrowed is removed from the plog or re-examined later. As written, the same object can be re-escrowed on a later firstPending trigger, causing a double decrement or a spurious abort when funds are insufficient; alternatively, if the occurrence is removed as confirmed, the other instance may later abort a transaction that was already reported as committed. Lemma 5's proof restates the intended escrow semantics but does not establish exactly-once joint commit/abort across instances, so the atomicity guarantee does not follow from the algorithm.
  2. [Section V-B, Algorithm 1 lines 4-6; Lemma 1] The block state tuple S is load-bearing for the correctness of partial ordering, but the paper does not specify how a leader computes S, how pullValidTx validates transactions against S, or how cross-instance dependencies are discovered and encoded in block references. The running example in Appendix B illustrates one intended scenario, but it is not a protocol definition. Lemma 1 asserts that replicas in the same state execute the same set of transactions because each block refers to an agreed state b.S; however, a Byzantine leader can propose a stale or inconsistent S, and the failure-detector discussion only treats invalid transactions as post-hoc evidence of misbehavior. Without a precise definition of valid state references and a proof that honest replicas derive the same validation outcomes from them, Lemma 1 does not follow from the SB agreement property alone.
  3. [Section V-C, Algorithm 1 lines 32-41; Lemma 5] The global-log execution path has the same cross-instance coordination gap for contract transactions. When the last occurrence of a contract transaction is executed against the glog, the replica checks allEscrowed(tx) against its local elog. If the escrow from another instance has not yet been processed locally, the transaction can be aborted even though all payers would eventually escrow; if the other instance has already committed and removed its escrow entries, allEscrowed(tx) can become false and cause an abort after a commit has been reported. The pseudocode gives no synchronization or ordering between per-instance escrow processing and the global-log execution, so the atomicity and consistency guarantees claimed in Lemma 5 and Theorem 1 are not established for contract transactions either.
  4. [Section VI, Lemma 1 and Lemma 2 proofs] The correctness proof assumes that a payment transaction valid under block state b.S will succeed under b.S or any subsequent state derived from it, but the paper's own examples in Section II-A show that success can depend on the order in which decrements are applied when balances are limited. Since Orthrus executes payment transactions concurrently and asynchronously across instances, two honest replicas can reach the same state S with different intermediate escrow histories; the paper does not provide an invariant that would make validity outcomes identical across replicas. Lemma 2's summation formula also only applies after a fixed set T is known to succeed, so it does not address the required agreement on which transactions succeed and which fail. The safety argument therefore needs an additional invariant connecting per-instance escrow state to the block-state tuple S.
minor comments (5)
  1. [Abstract and Section VII] There are formatting typos: 'W AN' appears with a space in the abstract and in several places in Section VII, and 'V AN' appears in the abstract.
  2. [Figure 2 caption] The caption refers to the 'executions module' while the text and architecture consistently name it the 'execution module'; please make the terminology uniform.
  3. [Algorithm 2, line 8] The line 'allEscrowed(tx) ← true' uses the function name as if it were a local variable; please rename the local boolean (e.g., 'ok') to avoid confusion.
  4. [Section V-C, Algorithm 1 line 20] The execution trigger 'firstPending(plog[i])' does not specify how the index i is chosen in the concurrent execution module, nor how multiple per-instance execution threads interact when they touch the same transaction; please clarify the execution thread model.
  5. [Appendix A] The paper imports the dynamic global ordering algorithm from Ladon [19] without stating the precise theorem it relies on; please add an explicit statement of the agreement and monotonicity properties being assumed, even if the proof is delegated to the earlier paper.

Circularity Check

2 steps flagged · score 5.0 of 10

Safety and atomicity proofs lean on a same-author citation and on restating the escrow design rather than deriving it from the pseudocode; the payment-path performance claims are otherwise empirically self-contained.

  1. self citation load bearing [Section V-B (Order Transactions) and Appendix A (Global Ordering Algorithm)]
    "To achieve this, Orthrus adopts the dynamic global ordering algorithm from Ladon [19], which is detailed in Appendix A. ... A detailed description and formal proof can be found in [19]."

    Lemma 1 and Theorem 1 establish safety for contract transactions by asserting that globally ordered transactions are executed in the same sequence and under the same state. The only support for this agreement property is the Ladon rank Agreement and Monotonicity claims, whose proof is cited to [19] rather than given in this paper. Six of this paper's seven authors are authors of [19], so the load-bearing correctness step for the contract-transaction half of the system rests on an unshown same-author citation rather than an independent derivation.

  2. self definitional [Section IV-C Solution-I and Section VI Lemma 5 (Atomicity)]
    "However, if any escrow request fails, all escrows associated with this transaction are canceled, and the amounts are refunded to the respective payers. ... According to this mechanism, if any sub-transaction fails during the escrow phase, all associated escrow requests of tx are aborted, meaning that all sub-transactions will be aborted. ... Thus, the atomicity of the transaction is preserved."

    The atomicity guarantee that Lemma 5 must prove is already part of the escrow mechanism's specification in Solution-I: failure of any escrow cancels all escrows for the transaction. The lemma's proof then says 'According to this mechanism' the failure aborts all requests, and concludes atomicity. The proof does not show how Algorithm 1's independent per-instance execution loops propagate a failure in one instance to the other occurrence of the same transaction; no cross-instance abort or commit step appears in the pseudocode. The desired theorem is therefore the mechanism's definitional promise restated as the conclusion, not a result derived from the algorithm.

full rationale

The evaluation against ISS, RCC, Mir-BFT, DQBFT, and Ladon on 128 replicas with real Ethereum data is an external test of the throughput and latency claims; there are no fitted parameters renamed as predictions, and the single-payer payment path is a genuine algorithmic construction. Circularity is therefore partial rather than total. Two load-bearing arguments are self-referential: the global-ordering agreement property for contract transactions is imported from a same-author paper without an independent proof here, and the multi-payer atomicity lemma restates the escrow design's intended behavior instead of deriving it from the pseudocode. These issues leave two central safety and atomicity guarantees dependent on self-referential support, while the empirical results and the single-payer partial-ordering design retain independent content, which motivates a score between the minor-self-citation level and the full by-construction level.

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

The protocol is a system design rather than a derivation, so the ledger is dominated by domain assumptions about the BFT model, the SB abstraction, and the imported Ladon global ordering algorithm. The main ad hoc assumption is the sufficiency of the block state tuple S for cross-instance dependency ordering, which is not fully specified.

assumptions (5)
  • domain assumption The system is partially synchronous and has n >= 3f+1 replicas with at most f Byzantine failures.
    Section III-A defines the standard BFT system model used throughout the protocol.
  • domain assumption The sequenced broadcast (SB) black box guarantees agreement and termination for every sequence number.
    Section III-C defines SB as a black box with these properties; Lemmas 1 and 6 rely on them.
  • domain assumption Ladon's dynamic global ordering algorithm satisfies agreement and monotonicity of ranks.
    Section V-B and Appendix A import the algorithm and its properties from [19], which shares authors with this paper; no independent proof is given here.
  • domain assumption Payment transactions, defined as transactions over owned objects with only incremental/decremental operations, are commutative across different payer accounts.
    Section II-A and Lemma 2 rely on the final balance being the sum of increments minus decrements, independent of order across instances.
  • ad hoc to paper A block's state tuple S, chosen by the leader, is a sufficient and consistent snapshot for validating all transactions in the block and for establishing cross-instance partial order.
    Algorithm 1 lines 5-6 use b.S to pull valid transactions, but the mechanism to ensure the referenced state is consistent with dependencies is only illustrated in Appendix B, not specified as an algorithm.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Orthrus: Accelerating Multi-BFT Consensus through Concurrent Partial Ordering of Transactions (Extended Version)." pith.science (2026). https://pith.science/paper/WIKO2GJH

@misc{pith2026250114732,
  author       = {Pith},
  title        = {Pith review of: Orthrus: Accelerating Multi-BFT Consensus through Concurrent Partial Ordering of Transactions (Extended Version)},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WIKO2GJH}},
  note         = {Machine review of arXiv:2501.14732}
}
read the original abstract

Multi-Byzantine Fault Tolerant (Multi-BFT) consensus allows multiple consensus instances to run in parallel, resolving the leader bottleneck problem inherent in classic BFT consensus. However, the global ordering of Multi-BFT consensus enforces a strict serialized sequence of transactions, imposing additional confirmation latency and also limiting concurrency. In this paper, we introduce Orthrus, a Multi-BFT protocol that accelerates transaction confirmation through partial ordering while reserving global ordering for transactions requiring stricter sequencing. To this end, Orthrus strategically partitions transactions to maximize concurrency and ensure consistency. Additionally, it incorporates an escrow mechanism to manage interactions between partially and globally ordered transactions. We evaluated Orthrus through extensive experiments in realistic settings, deploying 128 replicas in WAN and LAN environments. Our findings demonstrate latency reductions of up to 87% in WAN compared to existing Multi-BFT protocols.

Figures

Figures reproduced from arXiv: 2501.14732 by the authors.

Figure 1
Figure 1. (a) Multi-BFT paradigm. The jth block produced by instance i is denoted as Bi j . (b) Breakdown latency with a straggler. The green bar refers to transaction transmission delay (① and ④), the orange refers to the delay of a block being delivered from consensus (②), and the black refers to the global ordering delay (③). of blocks, which are then ordered into a global sequence, as shown in Fig. 1a. By the global order… view at source ↗
Figure 2
Figure 2. An overview of Orthrus. Transactions are parti￾tioned into distinct buckets, ordered according to their types, and finally executed. transactions as input. Each instance has a leader who broad￾casts transactions with sequence numbers and coordinates all replicas to deliver a sequence of transactions. Transactions are executed after being partially ordered within an SB instance or globally ordered across instances. A… view at source ↗
Figure 4
Figure 4. Throughput and latency of Orthrus, ISS, RCC, Mir, DQBFT, and Ladon in LAN. We measure the peak throughput in kilo-transactions per sec￾ond (ktps) before reaching saturation, along with the associated latency in seconds (s). 1) Performance in WAN. Fig. 3a and Fig. 3c demonstrate that Orthrus consistently maintains throughput within the top tier. Without stragglers, Orthrus shows very similar throughput with ISS and R… view at source ↗
Figures from the paper (4 more)
Figure 6
Figure 6. Figure 6: Breakdown of latency in ISS versus Orthrus. stage covers when f + 1 replicas confirm the transaction to when the client receives f + 1 replies. The experiment was conducted in WAN with 16 replicas and one straggler. For each stage, the average time across all transacti…
Figure 7
Figure 7. Figure 7: Throughput and latency average of Orthrus over time with 0, 1, 5 faults. The faults occur at 9 seconds. 0 1 2 3 4 5 Number of faulty replicas 0 10 20 30 40 50 60 T h r o u g h p u t ( k t p s ) (a) Throughput 0 1 2 3 4 5 Number of faulty replicas 8 7 6 5 4 3 2 1 0 L a …
Figure 8
Figure 8. Figure 8: Throughput and latency of Orthrus under dif￾ferent number of undetectable faulty replicas in WAN. impact scales with the number of faults. During the decline in throughput, latency remains nearly unchanged. This is because transactions confirmed in this phase are from …
Figure 9
Figure 9. Figure 9: Protocol running example with two instances, three [PITH_FULL_IMAGE:figures/full_fig_p015_9.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. Prefix Consensus For Censorship Resistant BFT

    cs.DC 2026-02 conditional novelty 8.0 of 10

    Prefix Consensus, a new primitive where parties output consistent low/high prefixes, is solvable asynchronously in exactly three rounds, and yields leaderless BFT consensus with at most f censored slots after GST.

Reference graph

Works this paper leans on

70 extracted references · 68 canonical work pages · cited by 1 Pith paper

  1. [1]

    The Bedrock of Byzantine Fault Tolerance: A Unified Platform for BFT Protocols Analysis, Implementation, and Experimentation

    Mohammad Javad Amiri, Chenyuan Wu, Divyakant Agrawal, Amr El Abbadi, Boon Thau Loo, and Mohammad Sadoghi. The Bedrock of Byzantine Fault Tolerance: A Unified Platform for BFT Protocols Analysis, Implementation, and Experimentation. In NSDI, 2024

    work page 2024

  2. [2]

    Caper: a Cross-Application Permissioned Blockchain

    Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. Caper: a Cross-Application Permissioned Blockchain. In PVLDB, 2019

    work page 2019

  3. [3]

    ResilientDB: Global Scale Resilient Blockchain Fabric

    Suyash Gupta, Sajjad Rahnama, Jelle Hellings, and Mohammad Sadoghi. ResilientDB: Global Scale Resilient Blockchain Fabric. In PVLDB, 2020

    work page 2020

  4. [4]

    Proof-of-Execution: Reaching Consensus Through Fault- Tolerant Speculation

    Suyash Gupta, Jelle Hellings, Sajjad Rahnama, and Mohammad Sadoghi. Proof-of-Execution: Reaching Consensus Through Fault- Tolerant Speculation. In EDBT, 2021

    work page 2021

  5. [5]

    Blockchains vs

    Pingcheng Ruan, Tien Tuan Anh Dinh, Dumitrel Loghin, Meihui Zhang, Gang Chen, Qian Lin, and Beng Chin Ooi. Blockchains vs. Distributed Databases: Dichotomy and Fusion. In SIGMOD, 2021

    work page 2021

  6. [6]

    SodsBC: A Post-quantum by Design Asynchronous Blockchain Framework

    Shlomi Dolev, Bingyong Guo, Jianyu Niu, and Ziyu Wang. SodsBC: A Post-quantum by Design Asynchronous Blockchain Framework. In TDSC, 2023

    work page 2023

  7. [7]

    Algorand: Scaling Byzantine Agreements for Cryptocur- rencies

    Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nicko- lai Zeldovich. Algorand: Scaling Byzantine Agreements for Cryptocur- rencies. In SOSP, 2017

    work page 2017

  8. [8]

    Dfin- ity technology overview series, consensus system

    Timo Hanke, Mahnush Movahedi, and Dominic Williams. Dfin- ity technology overview series, consensus system. arXiv preprint arXiv:1805.04548, 2018

    arXiv 2018

Show all 70 references
  1. [9]

    The Quest for Scalable Blockchain Fabric: Proof-of- Work vs

    Marko Vukoli ´c. The Quest for Scalable Blockchain Fabric: Proof-of- Work vs. BFT Replication. In Open Problems in Network Security , 2016

    2016

  2. [10]

    Blockchain in the Lens of BFT

    Dahlia Malkhi. Blockchain in the Lens of BFT. In ATC, 2018

    2018

  3. [11]

    SoK: Decentralized Finance (DeFi)

    Sam Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Do- minik Harz, and William Knottenbelt. SoK: Decentralized Finance (DeFi). In AFT, 2022

    2022

  4. [12]

    Double- spending Fast Payments in Bitcoin

    Ghassan O Karame, Elli Androulaki, and Srdjan Capkun. Double- spending Fast Payments in Bitcoin. In CCS, 2012

    2012

  5. [13]

    Practical Byzantine Fault Tolerance

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

    1999

  6. [14]

    Dissecting the Performance of Chained-BFT

    Fangyu Gai, Ali Farahbakhsh, Jianyu Niu, Chen Feng, Ivan Beschast- nikh, and Hao Duan. Dissecting the Performance of Chained-BFT. In ICDCS, 2021

    2021

  7. [15]

    FnF-BFT: A BFT Protocol with Provable Performance under Attack

    Zeta Avarikioti, Lioba Heimbach, Roland Schmid, Laurent Vanbever, Roger Wattenhofer, and Patrick Wintermeyer. FnF-BFT: A BFT Protocol with Provable Performance under Attack. In SIROCCO, 2023

    2023

  8. [16]

    State Machine Replication Scalability Made Simple

    Chrysoula Stathakopoulou, Matej Pavlovic, and Marko Vukoli ´c. State Machine Replication Scalability Made Simple. In EuroSys, 2022

    2022

  9. [17]

    RCC: Resilient Concurrent Consensus for High-throughput Secure Transaction Process- ing

    Suyash Gupta, Jelle Hellings, and Mohammad Sadoghi. RCC: Resilient Concurrent Consensus for High-throughput Secure Transaction Process- ing. In ICDE, 2021

    2021

  10. [18]

    Mir-BFT: Scalable and Robust BFT for Decentralized Networks

    Chrysoula Stathakopoulou, Tudor David, and Marko Vukolic. Mir-BFT: Scalable and Robust BFT for Decentralized Networks. JSys, 2022

    2022

  11. [19]

    Ladon: High-Performance Multi-BFT Consensus via Dynamic Global Ordering

    Hanzheng Lyu, Shaokang Xie, Jianyu Niu, Chen Feng, Yinqian Zhang, and Ivan Beschastnikh. Ladon: High-Performance Multi-BFT Consensus via Dynamic Global Ordering. In EuroSys, 2025

    2025

  12. [20]

    Cryptocurrencies without Proof of Work

    Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. Cryptocurrencies without Proof of Work. In FC, 2016

    2016

  13. [21]

    Online Payments by Merely Broadcasting Messages

    Daniel Collins, Rachid Guerraoui, Jovan Komatovic, Petr Kuznetsov, Matteo Monti, Matej Pavlovic, Yvonne-Anne Pignolet, Dragos-Adrian Seredinschi, Andrei Tonkikh, and Athanasios Xygkis. Online Payments by Merely Broadcasting Messages. In DSN, 2020

    2020

  14. [22]

    The Escrow Transactional Method

    Patrick E O’Neil. The Escrow Transactional Method. TODS, 1986

    1986

  15. [23]

    https://go.dev/

    Golang. https://go.dev/

  16. [24]

    Scalable byzantine fault tolerance via partial decentralization

    Balaji Arun and Binoy Ravindran. Scalable byzantine fault tolerance via partial decentralization. VLDB, 2022

    2022

  17. [25]

    Consensus in the Presence of Partial Synchrony

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

    1988

  18. [26]

    Reiter, Guy Golan Gueta, and Ittai Abraham

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

    2019

  19. [27]

    Commutativity-based Concurrency Control for Ab- stract Data Types

    William E Weihl. Commutativity-based Concurrency Control for Ab- stract Data Types. IEEE Trans Comput , 1988

    1988

  20. [28]

    Sui Lutris: A Blockchain Combining Broadcast and Consensus

    Same Blackshear, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Xun Li, Mark Logan, Ashok Menon, Todd Nowacki, Alberto Sonnino, et al. Sui Lutris: A Blockchain Combining Broadcast and Consensus. In CCS, 2024

    2024

  21. [29]

    Introduction to Reliable and Secure Distributed Programming

    Christian Cachin, Rachid Guerraoui, and Lu ´ıs Rodrigues. Introduction to Reliable and Secure Distributed Programming. In Springer Science & Business Media , 2011

    2011

  22. [30]

    Practical Byzantine Fault Tolerance and Proactive Recovery

    Miguel Castro and Barbara Liskov. Practical Byzantine Fault Tolerance and Proactive Recovery. TOCS, 2002

    2002

  23. [31]

    FireLedger: A High Throughput Blockchain Consensus Protocol

    Yehonatan Buchnik and Roy Friedman. FireLedger: A High Throughput Blockchain Consensus Protocol. VLDB, 2020

    2020

  24. [32]

    SBFT: a scalable and decentralized trust infrastruc- ture

    Guy Golan Gueta, Ittai Abraham, Shelly Grossman, Dahlia Malkhi, Benny Pinkas, Michael Reiter, Dragos-Adrian Seredinschi, Orr Tamir, and Alin Tomescu. SBFT: a scalable and decentralized trust infrastruc- ture. In DSN, 2019

    2019

  25. [33]

    Zyzzyva: Speculative Byzantine Fault Tolerance

    Ramakrishna Kotla, Lorenzo Alvisi, Mike Dahlin, Allen Clement, and Edmund Wong. Zyzzyva: Speculative Byzantine Fault Tolerance. SIGOPS, 2007

    2007

  26. [34]

    Tendermint: Byzantine Fault Tolerance in the Age of Blockchains

    Ethan Buchman. Tendermint: Byzantine Fault Tolerance in the Age of Blockchains. M.Sc. Thesis, University of Guelph, Canada , 2016

    2016

  27. [35]

    Scalable Byzantine Consensus via Hardware-Assisted Secret Sharing

    Jian Liu, Wenting Li, Ghassan O Karame, and Nadarajah Asokan. Scalable Byzantine Consensus via Hardware-Assisted Secret Sharing. IEEE Trans. Comput , 2018

    2018

  28. [36]

    Byzantine Protocols with Asymptotically Optimal Communication Complexity

    Hanzheng Lyu, Shaokang Xie, Jianyu Niu, and Chen Feng. Byzantine Protocols with Asymptotically Optimal Communication Complexity. In SecureComm, 2023

    2023

  29. [37]

    Fast- Hotstuff: A Fast and Robust BFT Protocol for Blockchains

    Mohammad M Jalalzai, Jianyu Niu, Chen Feng, and Fangyu Gai. Fast- Hotstuff: A Fast and Robust BFT Protocol for Blockchains. TDSC, 2023

    2023

  30. [38]

    The Hermes BFT for Blockchains

    Mohammad M Jalalzai, Chen Feng, Costas Busch, Golden G Richard, and Jianyu Niu. The Hermes BFT for Blockchains. TDSC, 2021

    2021

  31. [39]

    EBFT: Simplifying BFT Consensus Through Egalitarianism

    Jianyu Niu, Runchao Han, Shengqi Liu, Fangyu Gai, Ivan Beschastnikh, Yinqian Zhang, and Chen Feng. EBFT: Simplifying BFT Consensus Through Egalitarianism. In arXiv preprint arXiv:2012.01636 , 2020

    2012 arXiv

  32. [40]

    Bottlenecks in Blockchain Consensus Protocols

    Salem Alqahtani and Murat Demirbas. Bottlenecks in Blockchain Consensus Protocols. In COINS, 2021

    2021

  33. [41]

    PigPaxos: Devouring the Communication Bottlenecks in Distributed Consensus

    Aleksey Charapko, Ailidani Ailijiang, and Murat Demirbas. PigPaxos: Devouring the Communication Bottlenecks in Distributed Consensus. In SIGMOD, 2021

    2021

  34. [42]

    Scaling Blockchain Consensus via a Robust Shared Mempool

    Fangyu Gai, Jianyu Niu, Ivan Beschastnikh, Chen Feng, and Sheng Wang. Scaling Blockchain Consensus via a Robust Shared Mempool. In ICDE, 2023

    2023

  35. [43]

    Network Robustness to Targeted Attacks

    Ernesto Estrada. Network Robustness to Targeted Attacks. The Interplay of Expansibility and Degree Distribution. EPJ B, 2006

    2006

  36. [44]

    TELL: Efficient Transaction Execution Protocol Towards Leaderless Consensus

    Xing Tong, Zheming Ye, Zhao Zhang, Cheqing Jin, and Aoying Zhou. TELL: Efficient Transaction Execution Protocol Towards Leaderless Consensus. In ICDE, 2024

    2024

  37. [45]

    Cryptoconcurrency: (Almost) Consensusless Asset Transfer with Shared Accounts

    Andrei Tonkikh, Pavel Ponomarev, Petr Kuznetsov, and Yvonne-Anne Pignolet. Cryptoconcurrency: (Almost) Consensusless Asset Transfer with Shared Accounts. In CCS, 2023

    2023

  38. [46]

    Asynchronous Proof-of-Stake

    Jakub Sliwinski and Roger Wattenhofer. Asynchronous Proof-of-Stake. In SSS, 2021

    2021

  39. [47]

    Fastpay: High- Performance Byzantine Fault Tolerant Settlement

    Mathieu Baudet, George Danezis, and Alberto Sonnino. Fastpay: High- Performance Byzantine Fault Tolerant Settlement. In AFT, 2020

    2020

  40. [48]

    Flash: An Asyn- chronous Payment System with Good-Case Linear Communication Complexity

    Andrew Lewis-Pye, Oded Naor, and Ehud Shapiro. Flash: An Asyn- chronous Payment System with Good-Case Linear Communication Complexity. In arXiv preprint arXiv:2305.03567 , 2023

    2023 arXiv

  41. [49]

    Money Transfer Made Simple: a Specification, a Generic Algorithm, and its Proof

    Alex Auvolat, Davide Frey, Michel Raynal, and Franc ¸ois Ta¨ıani. Money Transfer Made Simple: a Specification, a Generic Algorithm, and its Proof. In arXiv preprint arXiv:2006.12276 , 2020

    2006

  42. [50]

    Permissionless and Asynchronous Asset Transfer

    Petr Kuznetsov, Yvonne-Anne Pignolet, Pavel Ponomarev, and Andrei Tonkikh. Permissionless and Asynchronous Asset Transfer. In Distrib Comput, 2023

    2023

  43. [51]

    All You Need is DAG

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

    2021

  44. [52]

    Narwhal and Tusk: a DAG-Based Mempool and Efficient BFT Consensus

    George Danezis, Lefteris Kokoris-Kogias, Alberto Sonnino, and Alexan- der Spiegelman. Narwhal and Tusk: a DAG-Based Mempool and Efficient BFT Consensus. In EuroSys, 2022

    2022

  45. [53]

    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

  46. [54]

    Shoal: Improving DAG-BFT Latency and Robustness

    Alexander Spiegelman, Balaji Arun, Rati Gelashvili, and Zekun Li. Shoal: Improving DAG-BFT Latency and Robustness. 2024

    2024

  47. [55]

    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

  48. [56]

    MYSTICETI: Reaching the Latency Limits with Uncertified DAGs

    Kushal Babel, Andrey Chursin, George Danezis, Anastasios Kichidis, Lefteris Kokoris-Kogias, Arun Koshy, Alberto Sonnino, and Mingwei Tian. MYSTICETI: Reaching the Latency Limits with Uncertified DAGs. In NDSS, 2025

    2025

  49. [57]

    Chainspace: A Sharded Smart Contracts Platform

    Mustafa Al-Bassam, Alberto Sonnino, Shehar Bano, Dave Hrycyszyn, and George Danezis. Chainspace: A Sharded Smart Contracts Platform. In NDSS, 2018

    2018

  50. [58]

    Towards Scaling Blockchain Systems via Sharding

    Hung Dang, Tien Tuan Anh Dinh, Dumitrel Loghin, Ee-Chien Chang, Qian Lin, and Beng Chin Ooi. Towards Scaling Blockchain Systems via Sharding. In SIGMOD, 2019

    2019

  51. [59]

    BrokerChain: A Cross-Shard Blockchain Protocol for Account/Balance-based State Sharding

    Huawei Huang, Xiaowen Peng, Jianzhou Zhan, Shenyang Zhang, Yue Lin, Zibin Zheng, and Song Guo. BrokerChain: A Cross-Shard Blockchain Protocol for Account/Balance-based State Sharding. In INFOCOM, 2022

    2022

  52. [60]

    Byshard: Sharding in a Byzantine Environment

    Jelle Hellings and Mohammad Sadoghi. Byshard: Sharding in a Byzantine Environment. In VLDB, 2021

    2021

  53. [61]

    Gridb: Scaling Blockchain Database via Sharding and Off-Chain Cross-Shard Mechanism

    Zicong Hong, Song Guo, Enyuan Zhou, Wuhui Chen, Huawei Huang, and Albert Zomaya. Gridb: Scaling Blockchain Database via Sharding and Off-Chain Cross-Shard Mechanism. In VLDB, 2024

    2024

  54. [62]

    A Secure Sharding Protocol for Open Blockchains

    Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. A Secure Sharding Protocol for Open Blockchains. In CCS, 2016

    2016

  55. [63]

    Kokoris-Kogias, P

    E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford. OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. In S&P, 2018

    2018

  56. [64]

    Rapidchain: Scaling Blockchain via Full Sharding

    Mahdi Zamani, Mahnush Movahedi, and Mariana Raykova. Rapidchain: Scaling Blockchain via Full Sharding. In CCS, 2018

    2018

  57. [65]

    Sharper: Sharding Permissioned Blockchains over Network Clusters

    Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. Sharper: Sharding Permissioned Blockchains over Network Clusters. In SIGMOD, 2021

    2021

  58. [66]

    High Throughput Byzantine Fault Tolerance

    Ramakrishna Kotla and Michael Dahlin. High Throughput Byzantine Fault Tolerance. In DSN, 2004

    2004

  59. [67]

    On the Per- formance of Using Parallel State Machine Replication to Implement Blockchains

    Aldenio Burgos, Eduardo Alchieri, and Fernando Dotti. On the Per- formance of Using Parallel State Machine Replication to Implement Blockchains. In LADC, 2021

    2021

  60. [68]

    Partial Order Transactions on Permissioned Blockchains for Enhanced Scalability

    Krishnasuri Narayanam, Akshar Kaul, Ken Kumar, and Pankaj Dayama. Partial Order Transactions on Permissioned Blockchains for Enhanced Scalability. In BRAINS, 2021

    2021

  61. [69]

    SpotLess: Concurrent Rotational Consensus Made Practical Through Rapid View Synchronization

    Dakai Kang, Sajjad Rahnama, Jelle Hellings, and Mohammad Sadoghi. SpotLess: Concurrent Rotational Consensus Made Practical Through Rapid View Synchronization. In ICDE, 2024. APPENDIX A GLOBAL ORDERING ALGORITHM In this section, we introduce the dynamic global ordering algorith...

    2024

  62. [70]

    In Block 1 of Instance 0, $1 is escrowed from Alice’s account

    This dependency ensures that Bob’s transfer relies on the completion of tx0, where Bob receives sufficient balance. In Block 1 of Instance 0, $1 is escrowed from Alice’s account. Concurrently, in Block 0 of Instance 1, $1 is escrowed from Bob’s account. These operations can be...

Pith tools

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