REVIEW 3 major objections 5 minor
Multimmit: Extending Blocks for Faster Finality
T0 review · 3 major / 5 minor · reviewed 2026-08-04 · deepseek-v4-flash
Pith's one-line read Multimmit is a consensus protocol that claims a transaction block broadcast at time t is ordered by t+3δ on average (t+2δ at best), while a faulty producer can delay only its own chain's blocks.
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the vote vector with extensions. A vote for a leader block reports, for every chain, the highest position of the leader's proposal the voter has DA-voted for, and may attach up to e fresh block hashes beyond that position. This single message does three jobs: it lets consensus finalise after one round of voting, it lets fresh blocks race the vote event instead of the proposal event, and it makes the safe frontier leader-proof because extensions are anchored at the voter's reported position, not at the proposed tip. The argument's load-bearing identity is the pair of extraction rules (finalised tips discard the top 3f votes per chain; safe-to-extend tips discard the top
What would settle it
Construct an execution in which a faulty producer discloses a block to exactly one correct processor, that processor later stops responding, and check whether the block's transactions ever enter any honest log; if they do not, the extractable-liveness claim fails.
Extended reading notes
Core claim
The paper's core discovery is that latency and fragility in parallel-dissemination SMR can both be addressed by letting votes, not proposals, carry fresh blocks. Each leader proposes a chain proposal listing tips for every chain without requiring those blocks to be certified or held by voters; each voter sends one vote reporting, per chain, how far it can support the proposal, and optionally extends beyond the proposed tip with up to e fresh blocks it has already data-availability-voted for. Because a transaction block only needs to reach voters before they vote—not the leader before it proposes—the proposal leg disappears from the critical path. Two asymmetric extraction rules then do the w
Load-bearing premise
The claim that every emitted block's data can be retrieved depends on at least one correct processor holding each block and answering requests within 2δ after GST; the protocol guarantees such a holder exists, but only sometimes one, and the retrieval mechanism itself is left unspecified.
Editorial extensions
If this is right
- In the good case, a transaction block broadcast at time t is ordered by t+3δ on average (t+2δ at best), two message delays faster than the previous state of the art.
- In the common case with a correct leader and up to f faulty non-leaders, an honest chain's block is still finalised by t+3δ; its placement is delayed at most one view (t+5δ) if queued behind a lagging faulty chain.
- Faulty producers cannot spoil the optimistic path: each can delay only its own chain's blocks, so easy spoiling—withholding one early batch to void an entire proposal—has no analogue.
- No leader can both finalise its leader block and exclude a fresh well-circulated block from an honest chain; excluding it forces the leader to sacrifice the whole view.
- Consensus traffic stays in the tens of kilobytes per view independent of transaction volume, so throughput is bounded by data reception, not by consensus messages.
Reading between the lines
- The latency numbers are measured from block dissemination, not from the leader's proposal; under the older convention the claimed figure would be 2δ, so comparisons with other protocols must use the same clock to be meaningful.
- Because the protocol solves Extractable SMR rather than full SMR, the liveness guarantee rests on an unmodelled retrieval mechanism; a deployment where the single guaranteed holder of an emitted block is faulty or silent would see that block's transactions stall.
- The unanimity requirement for extension finality suggests a testable stress point: an equivocating producer might cause in-view order finality to defer, even though membership finality survives; measuring how often this occurs under equivocation would quantify how often the optimistic path degrades.
- The one-view placement wait for other chains could likely be shrunk by a deterministic blame or reputation rule, and the paper sketches such rules; that is a natural next step for engineering, not part of the paper's formal guarantees.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes Multimmit, a partially-synchronous BFT SMR protocol for n≥5f+1 that combines a Minimmit-style single-round-of-voting consensus layer with per-producer transaction chains. Leaders propose per-chain tips; voters return vector votes reporting per-chain support and may attach extension votes attesting fresh blocks beyond the proposal. The paper formalises extraction rules for L-QCs and V-QCs, proves consistency (Theorem 1), liveness (Theorem 2), a block-inclusion/censorship-resistance theorem (Theorem 3), and exact thresholds for extension finality (Theorem 4). It claims a transaction block disseminated at time t is ordered by t+3δ in expectation and t+2δ at best, with graceful degradation under faults.
Significance. The design is a reasonable and nontrivial development over Raptr and Autobahn, and the formal core is substantial. The proofs of Lemmas 1–13 and Theorems 1–4 are detailed and, on inspection, internally consistent; the quorum-intersection arguments behind the extraction rules, the damage-localisation lemma, and the block-inclusion theorem are genuine contributions. The paper also gives concrete size estimates (Section 3.8) that support the bandwidth claims. However, the headline latency claim is only argued informally, the manuscript is incomplete (Sections 7–8 are placeholders), and the liveness theorem is stated for Extractable SMR under an unmodelled retrieval convention. These issues are load-bearing for the paper's main advertised contributions, so the manuscript is not yet publishable in its present form.
major comments (3)
- [Sections 7–8 (and end of Section 6)] The submission is incomplete: Section 7 is 'Experiments [Andy: To be added]', Section 8 is 'Related work [Andy: To be written]', and Section 6 ends with '[Further items to include...]'. No experimental or simulation evidence supports the quantitative comparison with Raptr in Section 3.6, and the related-work positioning is missing. This is not a local presentation issue; the paper as submitted lacks two of its advertised sections.
- [§3.6 and §5.2] The abstract's headline claim that a block disseminated at time t is ordered by t+3δ in expectation is not formally derived. Section 3.6 gives informal average-case reasoning—block reaches voters by t+δ, 'waits on average δ for the next vote event', then one round of voting—but Lemma 11 in Section 5 only bounds finalisation relative to the first correct processor's entry into a view. No theorem connects block dissemination time t to the view-entry time, and no probability space is defined for 'in expectation'. The 'common case' t+5δ placement figure is similarly unsupported. This needs either a formal latency lemma or an explicit downgrading to heuristic estimates.
- [§2 and §5.2 (Lemma 12)] The liveness guarantee is for Extractable SMR, not full SMR as the abstract states. Section 2 says retrieval of missing blocks is left to implementation, and Section 5.2 adds a convention that correct holders answer retrieval requests within 2δ after GST. Lemma 12(b) guarantees only a single correct holder for some emitted blocks, and Algorithms 1–2 contain no retrieval mechanism. Theorem 2's 'within bounded further time' therefore depends on an unmodelled external step. Either specify and integrate the retrieval mechanism into the protocol and its proofs, or state the extractable scope explicitly in the title, abstract, and theorem statements.
minor comments (5)
- [§1.1] '15f−1≤n' appears to be a typographical artifact; the surrounding text and standard results suggest '5f+1≤n' (or at least '5f−1≤n') was intended.
- [§3.8] The good-case statement that all votes are standard w.r.t. a single E* is not accurate when a block is still in flight at the vote event, as Section 3.5 itself acknowledges. The size estimate should state the assumption 'no block in flight' explicitly.
- [§3.4 vs §4] The informal description of the L-QC sweep—'halts at the first slot at which some chain has fallen short of its proposed tip'—differs from the formal settledness condition in Section 4. A cross-reference or a short explanation of the difference would prevent confusion.
- [Figure 3] The figure/caption combination is hard to parse in text; a clearer diagram with labelled frontiers would help.
- [References] Several references are listed as arXiv preprints with 2026 dates (including the paper itself). Please confirm all cited items are publicly available and correctly dated before resubmission.
Circularity Check
No significant circularity: all central latency, finality, and extraction-threshold claims are derived in-paper; the Minimmit self-citation is discharged by independent proofs.
full rationale
Multimmit's headline latency figures are analytic timing claims from the protocol's own message pattern (block reaches voters in δ, waits on average δ for the next vote event, one voting round adds δ), not fitted predictions. The extraction rules are justified by quorum-intersection arguments and by the matching lower-bound construction of Theorem 4; the thresholds are not assumed as inputs. The one inherited component is the Minimmit one-round view-progression skeleton, cited as [21], but Section 5 re-proves the needed machinery: Lemma 2 (one vote per view), Lemma 3 (vote/novote exclusivity), Lemma 4 (designation), Lemma 5 (no nullification after an L-notarisation), Lemma 6 (leader-chain consistency), and Lemma 10 (view exit) are self-contained arguments rather than citations. The walk-through of Algorithm 2 lines 16–19 explains the progression mechanism directly. The liveness claim is conditional on the explicitly stated Extractable SMR convention that a correct holder answers retrieval requests after GST; this is a model boundary, not a quantity defined in terms of the result it supports. The paper's own caveats—retrieval as an implementation detail, missing experiments, and non-formal accountability—are limitations and omitted material, not circular reductions. I found no equation or guarantee that reduces to its own inputs by construction.
Assumptions & free parameters
free parameters (3)
- pipelining depth d =
3 (example in the paper)
- extension bound e =
2
- batch bound B / production interval θ =
unspecified
assumptions (6)
- domain assumption Partial synchrony: after unknown GST, messages are delivered within Δ (and δ is the actual bound); before GST, arbitrary delay.
- standard math Authenticated point-to-point channels, PKI, collision-resistant hashes, aggregate (BLS) signatures and two threshold schemes; adversary is computationally bounded and cannot break them.
- domain assumption Correct processors' clocks proceed in real time; extension to bounded clock drift is deferred to 'standard arguments'.
- domain assumption Transactions are unique and each processor receives pending transactions from the environment; they are batched into blocks.
- domain assumption The protocol solves Extractable SMR: emitted block identifiers are guaranteed retrievable only via an unmodelled retrieval mechanism; retrieval is not part of the consensus protocol.
- standard math n ≥ 5f+1 and the lower-bound theorem that one-round voting finality requires 5f−1 ≤ n (or 5f+1 as assumed).
Cite this review
Pith. "Pith review of Multimmit: Extending Blocks for Faster Finality." pith.science (2026). https://pith.science/paper/SUDUBHXJ
@misc{pith2026260721021,
author = {Pith},
title = {Pith review of: Multimmit: Extending Blocks for Faster Finality},
year = {2026},
howpublished = {\url{https://pith.science/paper/SUDUBHXJ}},
note = {Machine review of arXiv:2607.21021}
}
abstract
To meet the throughput demands of modern blockchain systems, protocols for State Machine Replication (SMR) increasingly have many processors disseminate blocks of transactions in parallel, with consensus then establishing a total ordering on the blocks of all producers. Such designs face a choice as to when a block may enter the ordering. Certified approaches wait for a quorum to attest a block's availability, which is robust but adds message delays to every transaction. Uncertified approaches let proposals reference blocks immediately, which is fast but degrades rapidly when referenced data must be fetched on the critical path. Raptr, the state of the art, takes a middle course, finalising the longest prefix of the leader's proposal that a quorum holds, so that no processor ever blocks or fetches. The remaining weakness is sensitivity to order: if the data behind a single early batch is withheld, the proposal finalises little or nothing, so individual faulty producers can still deny the system its optimistic path. We present Multimmit, a protocol for $n \ge 5f+1$ processors combining a consensus layer requiring one round of voting per view with multi-chain data dissemination. Votes are cast relative to the leader's proposal, reporting per chain how far the voter can support it, and may themselves attest fresh blocks beyond it. A transaction block disseminated at time $t$ is ordered by $t+3\delta$ in expectation and $t+2\delta$ at best, measured from the block's dissemination rather than the leader's proposal. Degradation under faults is graceful: a faulty producer delays only its own chain's blocks, costing other chains at most a one-view wait for placement. No leader can both finalise its leader block and exclude a fresh, well-circulated block of an honest chain. Consensus traffic is tens of kilobytes per view, independent of transaction volume.
Figures
Figures from the paper (1 more)
Reviewed August 4, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.