Diagnosing High-Performance BFT Consensus via Mixture Modeling of Block Time Distributions

Akihiro Fujihara; Hongru He

REVIEW 4 major objections 5 minor 31 references

Diagnosing High-Performance BFT Consensus via Mixture Modeling of Block Time Distributions

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

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

Pith's one-line read Block times expose validator speed gaps in BFT chains

desk verdict Correct quorum-completion theory, but the validator-group reading of mixture weights doesn't follow from the model. read the letter →

arxiv 2608.01934 v1 pith:WNUROAJJ submitted 2026-08-03 cs.DC cs.CEcs.CRcs.PF

Hongru He , Akihiro Fujihara This is my paper · ORCID

classification cs.DCcs.CEcs.CRcs.PF

keywords ByzantinefaulttoleranceHotStuffblocktimedistributionquorummulticastmixturemodelhypoexponentialvalidatorheterogeneitylatencydiagnosis

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

This paper claims that the interval between consecutive blocks in HotStuff-style BFT blockchains is governed by quorum formation rather than full-committee broadcast, because a block advances once a quorum of validators has received it. The authors derive an exact closed-form distribution for that quorum-completion time and show that observed block-time histograms can be decomposed as finite mixtures of this distribution, one component per distinct effective transfer rate. On mainnet data, the fit is unimodal for Hyperliquid and persistently multimodal for Aptos, with a visible shift after Aptos's consensus upgrade. If the model holds, mixture weights and tail decay become practical signals for spotting validator heterogeneity and monitoring protocol changes.

What carries the argument

The load-bearing object is the quorum multicast completion time $T_M$: a continuous-time Markov chain on states $i=1,\dots,M$ where each uninformed validator receives the proposal at normalized rate $\lambda/N$, so the transition rate from state $i$ is $\alpha_i=(N-i)\lambda/N$. Because the sojourn times are independent exponentials, $T_M$ is a sum of exponentials—a hypoexponential distribution—whose Laplace transform factorizes and whose density after partial-fraction expansion is Eq. (14). The same object yields a Beta-form CDF (Eq. 15), harmonic-number mean and variance (Eqs. 17–18), an $O(\log N)$ correction for the parallel vote-collection phase (Eq. 25), and the mixture likelihood used for fitting (Eq. 8). The tail rate $\Lambda=(N-M+1)\lambda/N$ is what separates homogeneous (exponential) from heterogeneous (power-law) behavior in the empirical analysis.

What would settle it

Instrument a validator or testnet to record actual proposal-receipt times and compare the empirical $M$-of-$N$ order statistic with Eq. (14); if known correlated delays produce a power-law tail when the true rates are exponential, the independence assumption fails. Alternatively, measure block times on a chain where validator groups are deliberately split by latency and check whether the fitted mixture components track those groups.

Watch

Extended reading notes

Core claim

The central discovery is a distributional identity: the quorum multicast completion time $T_M$, defined as the time for a proposal to reach $M$ of $N$ validators under independent exponential per-validator delays with rate $\lambda/N$, has the closed-form density $$f_{T_M}(t)=\binom{N-1}{M-1}\frac{M-1}{N}\$\lambda$\,$e^{{-(N-M+1)\lambda t/N}}$\left(1-$e^{{-\lambda t/N}}$\right)^{M-2}$$ and its tail decays as a single exponential with rate $\Lambda=(N-M+1)\lambda/N$. The paper extends this to finite mixtures $p(t)=\sum_k w_k f_{T_M}(t;N,M_0,\lambda_k)$, fitted by expectation maximization, where each component represents a network condition with effective rate $\lambda_k$ and weight $w_k$. Applied to production data, Hyperliquid's block times are unimodal ($\hat\lambda=267.6$ s$^{-1}$, exponential tail), while Aptos before the BR upgrade needs three components and after it needs four, with all rates higher and a power-law tail; the authors read this as homogeneous versus heterogeneous validator deployments.

Load-bearing premise

The whole diagnostic reading rests on the assumption that each validator's receipt delay is independent and exponential at a common rate, so the quorum-completion time is an exact sum of exponentials, and that the observed block interval is essentially that quorum phase rather than a mix of other pipeline stages.

Editorial extensions

If this is right

Mixture weights $w_k$ and rates $\lambda_k$ give an operational partition of rounds by network condition, so a deployment can see what fraction of blocks are produced under each speed regime.
The aggregate expected block time reduces to $E[T_h]=N(H_{N-1}-H_{N-M})\sum_k w_k/\lambda_k$, meaning slow components contribute disproportionately through $w_k/\lambda_k$ and are the natural target for jailing or reputation-based leader selection.
Tail decay rate diagnoses homogeneity: exponential tails match a single effective rate, while power-law tails signal correlated delays or path-dependent mechanisms like payload fetch misses.
Protocol upgrades can be tracked by shifts in mixture structure; the Aptos BR upgrade raised all component rates and split one slow component into two, so mixture fits act as a monitoring instrument.
The model implies that as committee size grows, maintaining unimodal, exponentially-tailed block times becomes harder without explicit homogeneity enforcement, since the mean scales as $N$ and the parallel phase adds only $O(\log N)$.

Reading between the lines

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

The authors leave implicit that sliding the fitting window over time and tracking $\{w_k,\lambda_k\}$ would act as a change-point detector, flagging protocol upgrades or infrastructure shifts before the histogram shape alone makes them obvious.
A testable extension is that jailing and reputation mechanisms act on weights before rates: removing slow validators should lower the slow-component weight while leaving the remaining $\lambda_k$ roughly unchanged, a separation the model predicts and on-chain data could check.
If correlated cloud-region delays violate the independence assumption, the Beta-form CDF (Eq. 15) overestimates quorum-completion probability; simulating Eq. (14) under explicit correlated delays would show how far the fitted diagnostic parameters drift before the homogeneity reading flips.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Desk Editor's Note

read the letter

First thing you should know: the theory is the strong part. The exact quorum multicast distribution in Eq. (14) is a real, correctly derived contribution—it replaces the full-broadcast Gumbel asymptotics of prior work with the order statistic that actually matches certificate-driven BFT. Second thing: the empirical story overreaches. The stress-test note is right. In the mixture, w_k is the fraction of rounds governed by component k, not the fraction of validators in group k. A system with a permanently slow minority gives a quorum time based on order statistics with non-identical exponential rates, which is not the same as a finite mixture of identical-rate distributions. The paper even says w_k quantifies 'the fraction of rounds under that condition' in Section VI.A, but Section V.B turns components into 'a fast minority' and 'a slow component,' and Section VI.A recommends jailing slow validators. That semantic jump is load-bearing and it is not derived from the model.

The math deserves credit. The CTMC construction, the partial-fraction expansion, the beta CDF form, the moments, and the tail-asymptotic argument all check out. Fitting on mainnet data from Hyperliquid and Aptos is a real step beyond simulation, and the paper is honest about its independence assumptions and about the power-law tails in Aptos as a signal of correlation.

The empirical side has gaps you should know about. For Hyperliquid, the body-fit λ=267.6 s^-1 predicts a tail rate Λ≈101.9 s^-1 via Eq. (16), but the independently fitted empirical tail rate is 43.9 s^-1. That is a large discrepancy and the paper does not address it. The 0.4s truncation cap is justified by histogram separation, which is post-hoc. K is chosen by peak detection, which is reasonable but easily confounded by sample size, and there is no held-out validation, no confidence intervals, and no released code. These are fixable, not fatal.

Who should read this: anyone modeling BFT latency or monitoring production consensus chains. The theory is worth a serious referee, and the empirical section needs major revision, especially the identification of mixture weights with validator fractions. I would accept it for peer review, with the expectation that the authors either defend that identification or soften the diagnostic claims to what the model can actually support.

Referee Report

4 major / 5 minor

Summary. The paper proposes a diagnostic framework for HotStuff-based BFT blockchains in which the observed inter-block interval is modeled as the time for a proposal to reach a quorum of validators (quorum multicast completion time). The authors derive a closed-form distribution for this completion time as an order statistic of independent exponential receiver delays (Eqs. 10-16), extend it to finite mixtures representing distinct effective transfer-rate regimes, and fit the resulting body-and-tail models to mainnet block-time data from Hyperliquid and Aptos. They report that Hyperliquid is well described by a unimodal model with exponential tail decay, while Aptos is persistently multimodal and shows a shift after the Baby Raptr upgrade, and they interpret fitted mixture weights and rates as actionable diagnostics for validator heterogeneity.

Significance. The theoretical part of the paper is a genuine contribution: the exact closed-form quorum-completion distribution, its tail asymptotics, moment formulas, and the finite-N bound on the parallel phase are clearly derived and appear mathematically correct. If the identification were valid, the framework would offer a simple, on-chain-observable diagnostic for comparing BFT deployments and monitoring protocol upgrades. The paper gains credibility from using real mainnet data at scale (1.2M-10M blocks). However, the empirical validation has an unaddressed internal inconsistency, and the central diagnostic claim depends on an unvalidated semantic step from per-round mixture weights to validator-group shares. Because those issues are load-bearing, the paper's current significance is conditional on resolving them.

major comments (4)

[Section V-A, Eq. (16)] The Hyperliquid fit reports lambda = 267.6 s^-1 with N = 21 and M = 14. Using the paper's own Eq. (16), this implies a theoretical tail rate Lambda = (N - M + 1) lambda / N = (8 * 267.6) / 21 ≈ 101.9 s^-1. The empirical tail fit in the same section reports Lambda_tail = 43.9 s^-1, a factor of about 2.3 smaller. This discrepancy is not mentioned or reconciled. If the 90th-percentile tail fit is not intended to estimate the asymptotic rate, then comparing it to Eq. (16) is misleading; if it is intended as an empirical check, it contradicts the fitted body parameter. The claim that the agreement supports the homogeneous-network interpretation needs either a corrected comparison or an explicit explanation of how the two quantities are related.
[Section V-B and Section VI-A, Eq. (8)] Equation (8) is a mixture over block-time observations: each round is drawn from one of K order-statistic densities, each with a single global rate lambda_k, and w_k is the fraction of rounds generated under condition k. The paper itself states this in Section VI-A. However, Section V-B and the optimization discussion in Section VI-A interpret the same w_k as partitioning validators into performance groups ('a fast minority,' 'a majority group,' 'a slow component') and recommend jailing or reputation-weighting slow validators. These are different generative models: a fixed subset of permanently slow validators produces an (M-1)-th order statistic of exponentials with non-identical rates, which is not equal to a finite mixture of identical-rate order-statistic densities. The validator-group reading is therefore an additional identification assumption that is neither derived nor validated. This is load-bearing because the proposed diagnostic action—targeting slow validators—depends on that interpretation.
[Sections III-A, IV-D, and V] The model defines block time as T_h ≈ T_M + T_parallel, and Section IV-D argues that T_parallel contributes only O(log N) asymptotically. Yet all empirical fits use the density f_{T_M} in Eq. (14) alone, with no attempt to quantify T_parallel for the actual committee sizes (N = 21 and N ≈ 148). If T_parallel is not negligible at these finite sizes, the fitted lambda_k values are not clean 'effective transfer rates' but lumped parameters that absorb the omitted phase. To support the physical interpretation used throughout Section V and VI, the authors should either bound T_parallel numerically from their data or explicitly reframe lambda_k as effective aggregate parameters.
[Sections III-D and V] The empirical validation is entirely in-sample: lambda_k and w_k are estimated from the same block times they are later used to 'diagnose,' and no held-out data or predictive check is reported. Tail classification relies on comparing R^2 values of exponential and power-law fits without standard errors, confidence intervals, or formal goodness-of-fit tests. For a framework whose central promise is diagnostic monitoring, at least one falsifiable check—such as fitting on one time window and predicting the next, or a likelihood-ratio test against a nested alternative—should be provided.

minor comments (5)

[Table II and Fig. 4] The fitted parameters are reported without confidence intervals or standard errors; with 1.2M-10M samples even small departures will be statistically significant, so quantitative comparisons such as the '+63%' rate increase should include uncertainty estimates.
[Section III-C] The Hyperliquid analysis cutoff of t <= 0.4 s is described as 'inferred from histogram separation' without a concrete rule; this choice can materially affect the fitted rate and the tail analysis, so the criterion should be specified.
[Eq. (14)] The displayed density is difficult to parse because of the typesetting; please write the prefactor explicitly as \binom{N-1}{M-1}\frac{M-1}{N}\lambda and keep the exponential factors on one line.
[Section VI-A] The statement that upgrading or excluding the slow components 'yields approximately 10% latency reduction' is not derived in the text; please show the calculation using Eq. (29) or remove the specific percentage.
[Section V-B] The use of 'fraction of validators' in the main text conflicts with the correct statement in Section VI-A that w_k is the fraction of rounds under a condition; the wording should be made consistent throughout.

Circularity Check

1 steps flagged · score 3.0 of 10

Mixture weights fitted per round are relabeled as validator fractions; the diagnostic claim rests on that relabeling, while the theoretical quorum-time derivation itself is independent.

fitted input called prediction [Section V.B and Section VI.A (Eq. 8, EM M-step)]
"the fitted components partition validators into performance groups: a fast minority (w1=0.181, λ1=1213 s−1), a majority group (w2=0.703, λ2=919 s−1), and a slow component (w3=0.116, λ3=611 s−1). ... each λ_k characterizes a network condition, and w_k quantifies the fraction of rounds under that condition."

In Eq. (8) and the EM M-step (Section III-D), w_k is defined over block-time observations: w_k <- (1/n) Σ_i r_ik, i.e., the fraction of rounds assigned to component k. The model is a mixture over rounds, each with a single global rate λ_k. Section V.B reinterprets the same fitted w_k as the fraction of validators in performance groups, and Section VI.A turns it into an optimization target: 'Weight reduction targets w_k by excluding slow validators via jailing.' This identification is not derived from Eq. (14): a committee with persistently slow validators would have a completion time that is an order statistic of exponentials with non-identical rates, not a mixture of identical-rate order-statistic densities.

full rationale

The theoretical core of the paper, the quorum multicast completion-time distribution (Eqs. 4-16), is self-contained: starting from the stated CTMC assumption that each uninformed validator independently receives the proposal at rate λ/N, the hypoexponential order-statistic density follows by direct probabilistic derivation and is not fitted to data. The empirical sections are fitting exercises rather than held-out predictions; fitting unimodal vs mixture models and comparing exponential vs power-law tail fits on the same data is standard model selection, not circularity. The one substantive circularity-like step is the relabeling of the fitted mixture weights w_k, which the EM procedure defines as per-round mixing proportions, as validator fractions in Section V.B and as direct targets for jailing in Section VI.A. The paper itself states in VI.A that w_k quantifies 'the fraction of rounds under that condition,' so the validator-group reading is an additional, unvalidated identification assumption on which the diagnostic and optimization conclusions depend. The limitations section (VI.C) acknowledges correlations and interpretational caution but does not flag this semantic gap. Because the derivation of Eq. (14) remains independent and the central mathematical result is not forced by the data, the overall circularity is low but not zero.

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

The model rests on fitted rate/weight parameters and on several domain assumptions about timing independence and phase composition; it introduces no new physical entities, so the ledger is dominated by fitting parameters and idealizations.

free parameters (4)

Effective transfer rate lambda_k = Hyperliquid lambda=267.6 s^-1; Aptos pre-BR lambda=(1213, 918.9, 610.9) s^-1; Aptos post-BR lambda=(1971, 1603, 1080…
MLE/EM fit to block time body; each component's exponential arrival rate in the CTMC.
Mixture weight w_k = Hyperliquid 1.0; Aptos pre-BR (0.181, 0.703, 0.116); Aptos post-BR (0.273, 0.557, 0.065, 0.105)
EM-estimated mixture proportions assigned to each rate component.
Number of mixture components K = 1 (Hyperliquid), 3 (Aptos pre-BR), 4 (Aptos post-BR)
Set by histogram peak detection; a post-hoc model-selection choice explicitly preferred over BIC.
Empirical tail decay rate Lambda_tail = 43.9 s^-1 for Hyperliquid; Aptos tails fitted with power-law exponents 6.40 (pre-BR) and 4.47 (post-BR)
Obtained by separate fits to the 90th percentile tail; not derived from the body lambda, and for Hyperliquid it does not match the model-predicted Lambda approx 101.9 s^-1.

assumptions (4)

domain assumption Receiver delays are independent and exponentially distributed with common rate lambda/N.
Eq. (4) defines CTMC transition rates and Eq. (14) is the resulting order-statistic density; Section VI.C acknowledges independence is an idealization.
domain assumption Block time is approximated by the quorum multicast time T_M alone; the parallel completion phase T_parallel is neglected in the body fit.
Section III.D fits f_TM(t) directly to observed block times as a proxy; T_parallel is analyzed only asymptotically in Section IV.C-D.
domain assumption Quorum size is fixed as M0 = ceil(2N/3), and N is set to the number of distinct proposers observed in each window.
Section III.C; if the live validator set includes proposers not observed, or if the deployment uses a different quorum rule, fitted parameters change.
domain assumption Samples above the truncation cap are timeout-triggered and can be excluded.
Section III.C caps t at 0.4s (Hyperliquid, inferred from histogram) and 1.0s (Aptos, aligned with round_initial_timeout_ms), excluding possible view changes.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Diagnosing High-Performance BFT Consensus via Mixture Modeling of Block Time Distributions." pith.science (2026). https://pith.science/paper/WNUROAJJ

@misc{pith2026260801934,
  author       = {Pith},
  title        = {Pith review of: Diagnosing High-Performance BFT Consensus via Mixture Modeling of Block Time Distributions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WNUROAJJ}},
  note         = {Machine review of arXiv:2608.01934}
}

read the original abstract

High-performance Byzantine Fault Tolerant (BFT) blockchains are designed to achieve high throughput and low latency, yet their observed block time distributions often reveal complex behaviors arising from networking, pipelining, and deployment heterogeneity. In this paper, we diagnose HotStuff-based high-performance BFT consensus by modeling block times through a quorum-based multicast framework that links each block interval to quorum formation latency. We capture multimodal block time distributions using mixture models, where each component represents a distinct network condition characterized by effective transfer rate of block information. The proposed model is fitted to the bulk of mainnet block time data, while tail decay is analyzed separately to assess asymptotic behavior. Applying this methodology to Hyperliquid and Aptos mainnets, we find that Hyperliquid is well explained by a unimodal distribution, consistent with a relatively homogeneous validator deployment. In contrast, Aptos exhibits persistent multimodal structure and a pronounced shift following a consensus upgrade, reflecting heterogeneous deployments and diverse communication paths. These results demonstrate that mixture modeling of block time provides a practical and informative diagnostic tool for analyzing and monitoring high-performance BFT consensus.

Figures

Figures reproduced from arXiv: 2608.01934 by the authors.

**Figure 2.** State transition view of the quorum multicast completion time. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** Tail shape analysis of block time distributions for Hyperliquid and Aptos (pre-BR/post-BR). [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Global exact model fits for block time under the fixed quorum constraint [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]

Review history (2 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 25 canonical work pages

[1]

Towards robust distributed systems,

E. A. Brewer, “Towards robust distributed systems,” inProc. ACM Symposium on Principles of Distributed Computing (PODC), 2000. Keynote address

work page 2000
[2]

Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,

S. Gilbert and N. Lynch, “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,”ACM SIGACT News, vol. 33, no. 2, pp. 51–59, 2002

2002
[3]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf

2008
[4]

Gasper (LMD GHOST + Casper FFG) Consen- sus Specifications,

Ethereum Foundation, “Gasper (LMD GHOST + Casper FFG) Consen- sus Specifications,” online specification, accessed Dec. 2025. [Online]. Available: https://github.com/ethereum/consensus-specs

work page 2025
[5]

Aptos White Paper,

Aptos Labs, “Aptos White Paper,” 2022. [Online]. Available: https:// aptosnetwork.com/whitepaper/aptos-whitepaper en.pdf

work page 2022
[6]

Sui: A New Layer 1 Protocol,

Mysten Labs, “Sui: A New Layer 1 Protocol,” technical report / whitepaper, 2023. [Online]. Available: https://raw.githubusercontent. com/MystenLabs/sui/main/doc/paper/sui.pdf

work page 2023
[7]

HyperCore Overview,

Hyperliquid Docs, “HyperCore Overview,” online documentation, ac- cessed Dec. 2025. [Online]. Available: https://hyperliquid.gitbook.io/ hyperliquid-docs/hypercore/overview

work page 2025
[8]

Solana: A New Architecture for a High Performance Blockchain,

A. Yakovenko, “Solana: A New Architecture for a High Performance Blockchain,” whitepaper, 2018. [Online]. Available: https://solana.com/ solana-whitepaper.pdf

work page 2018

Show all 31 references

[9]

MonadBFT: Fast, responsive, fork-resistant streamlined consensus,

M. M. Jalalzai et al., “MonadBFT: Fast, responsive, fork-resistant streamlined consensus,”arXiv preprint arXiv:2502.20692, 2025

2025 arXiv
[10]

Practical Byzantine fault tolerance,

M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” inProc. OSDI, 1999

1999
[11]

HotStuff: BFT consensus in the lens of blockchain,

M. Yin, D. Malkhi, M. K. Reiter, G. Gueta, and I. Abraham, “HotStuff: BFT consensus in the lens of blockchain,” inProc. PODC, 2019

2019
[12]

Node repository and validator guide,

Hyperliquid, “Node repository and validator guide,” GitHub, 2024. [Online]. Available: https://github.com/hyperliquid-dex/node

2024
[13]

Revisiting Optimal Resilience of Fast Byzantine Consensus,

P. Kuznetsov, A. Tonkikh, and Y . X. Zhang, “Revisiting Optimal Resilience of Fast Byzantine Consensus,” inProc. ACM Symposium on Principles of Distributed Computing (PODC), 2021, pp. 343–353. Extended version: arXiv:2102.12825

2021 arXiv
[14]

Tendermint: Byzantine fault tolerance in the age of blockchains,

J. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,” Master’s thesis, University of Guelph, 2016

2016
[15]

The Libra Blockchain,

The Libra Team, “The Libra Blockchain,” 2019. [Online]. Available: https://developers.diem.com/papers/the-diem-blockchain/2019-06-25. pdf

2019
[16]

Jolteon and Ditto: Network adaptive efficient consensus with asynchronous fallback,

R. Gelashvili, L. Kokoris Kogias, A. Sonnino, A. Spiegelman, and Z. Xiang, “Jolteon and Ditto: Network adaptive efficient consensus with asynchronous fallback,”arXiv preprint arXiv:2106.10362, 2021

2021 arXiv
[17]

DiemBFT v4 Technical Documentation,

Diem authors, “DiemBFT v4 Technical Documentation,” 2021. [Online]. Available: https://developers.diem.com/papers/diem- consensus- state- machine-replication-in-the-diem-blockchain/2021-08-17.pdf

2021
[18]

Nar- whal and Tusk: A DAG-based mempool and efficient BFT consensus,

G. Danezis, L. Kokoris-Kogias, A. Sonnino, and A. Spiegelman, “Nar- whal and Tusk: A DAG-based mempool and efficient BFT consensus,” in Proc. 17th European Conf. Computer Systems (EuroSys), 2022, pp. 34– 50

2022
[19]

AIP-26: Quorum Store,

Aptos Foundation, “AIP-26: Quorum Store,” 2023. [Online]. Available: Aptos Foundation AIP-26

2023
[20]

Bullshark: DAG BFT protocols made practical,

A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris Kogias, “Bullshark: DAG BFT protocols made practical,” inProc. ACM CCS, 2022

2022
[21]

AIP-89: Consensus Latency Reduction using Order V otes

Aptos Foundation. “AIP-89: Consensus Latency Reduction using Order V otes.” Online specification, 2024. Aptos Foundation AIP-89

2024
[22]

Raptr: Prefix consensus for robust high-performance BFT,

A. Tonkikh, B. Arun, Z. Xiang, Z. Li, and A. Spiegelman, “Raptr: Prefix consensus for robust high-performance BFT,”arXiv preprint arXiv:2504.18649, 2025

2025 arXiv
[23]

Baby Raptr Is Here: a New Era of Consensus Begins,

Aptos, “Baby Raptr Is Here: a New Era of Consensus Begins,” Jun. 20, 2025. [Online]. Available: https://aptosnetwork.com/currents/baby- raptr-lands-on-mainnet

2025
[24]

A performance analysis of consensus time for blockchains,

J. D. Chan, Y . C. Tay, and B. R. Z. Yen, “A performance analysis of consensus time for blockchains,”ACM Trans. Model. Perform. Eval. Comput. Syst., vol. 10, no. 3, pp. 1–23, Mar. 2025

2025
[25]

Delay analysis of BFT consensus: Case study of Narwhal and Bullshark protocols,

K. Hwerbi, I. Amdouni, C. Adjih, L. A. Saidane, and A. Laouiti, “Delay analysis of BFT consensus: Case study of Narwhal and Bullshark protocols,”Computer Communications, vol. 242, article 108278, Oct. 2025

2025
[26]

Dissecting the performance of chained-BFT,

F. Gai, A. Farahbakhsh, J. Niu, C. Feng, I. Beschastnikh, and H. Duan, “Dissecting the performance of chained-BFT,” inProc. IEEE Int. Conf. Distributed Computing Systems (ICDCS), 2021, pp. 595–606

2021
[27]

Theoretical analysis on block time distributions in Byzan- tine fault–tolerant consensus blockchains,

A. Fujihara, “Theoretical analysis on block time distributions in Byzan- tine fault–tolerant consensus blockchains,” in2024 IEEE International Conference on Blockchain (Blockchain), Copenhagen, Denmark, 2024, pp. 378–385, doi: 10.1109/Blockchain62396.2024.00056

2024
[28]

Mitigation and resurgence of the scalability trilemma: Mathematical analysis for optimal sharding in dual–layer Byzantine fault–tolerant blockchains,

A. Fujihara, “Mitigation and resurgence of the scalability trilemma: Mathematical analysis for optimal sharding in dual–layer Byzantine fault–tolerant blockchains,”Distributed Ledger Technologies: Research and Practice, 2025. doi: 10.1145/3772080

2025 doi
[29]

Mathematical modelling of dual–layer Byzantine fault– tolerant consensus process for optimal sharding and mitigation of blockchain trilemma,

A. Fujihara, “Mathematical modelling of dual–layer Byzantine fault– tolerant consensus process for optimal sharding and mitigation of blockchain trilemma,” in2024 6th Conf. Blockchain Research & Ap- plications for Innovative Networks and Services (BRAINS), Berlin, Germany, 202...

2024
[30]

Exploring the universality of finality time in proof- of-stake blockchains: Empirical analysis and mathematical formula- tion of size-synchrony antagonism,

A. Fujihara, “Exploring the universality of finality time in proof- of-stake blockchains: Empirical analysis and mathematical formula- tion of size-synchrony antagonism,” in2025 IEEE International Conf. Blockchain and Cryptocurrency (ICBC), Pisa, Italy, 2025, pp. 1–5, doi: 10....

2025
[31]

Staking – Technical Details,

Hyperliquid Docs, “Staking – Technical Details,” online documentation, accessed Dec. 2025. [Online]. Available: https://hyperliquid.gitbook.io/ hyperliquid-docs/hypercore/staking#technical-details

2025

Pith tools

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

[1] [1]

Towards robust distributed systems,

E. A. Brewer, “Towards robust distributed systems,” inProc. ACM Symposium on Principles of Distributed Computing (PODC), 2000. Keynote address

work page 2000

[2] [2]

Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,

S. Gilbert and N. Lynch, “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,”ACM SIGACT News, vol. 33, no. 2, pp. 51–59, 2002

2002

[3] [3]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf

2008

[4] [4]

Gasper (LMD GHOST + Casper FFG) Consen- sus Specifications,

Ethereum Foundation, “Gasper (LMD GHOST + Casper FFG) Consen- sus Specifications,” online specification, accessed Dec. 2025. [Online]. Available: https://github.com/ethereum/consensus-specs

work page 2025

[5] [5]

Aptos White Paper,

Aptos Labs, “Aptos White Paper,” 2022. [Online]. Available: https:// aptosnetwork.com/whitepaper/aptos-whitepaper en.pdf

work page 2022

[6] [6]

Sui: A New Layer 1 Protocol,

Mysten Labs, “Sui: A New Layer 1 Protocol,” technical report / whitepaper, 2023. [Online]. Available: https://raw.githubusercontent. com/MystenLabs/sui/main/doc/paper/sui.pdf

work page 2023

[7] [7]

HyperCore Overview,

Hyperliquid Docs, “HyperCore Overview,” online documentation, ac- cessed Dec. 2025. [Online]. Available: https://hyperliquid.gitbook.io/ hyperliquid-docs/hypercore/overview

work page 2025

[8] [8]

Solana: A New Architecture for a High Performance Blockchain,

A. Yakovenko, “Solana: A New Architecture for a High Performance Blockchain,” whitepaper, 2018. [Online]. Available: https://solana.com/ solana-whitepaper.pdf

work page 2018