{"id":"d1b7624a-5fef-4c4f-8d24-3cd9cf943a97","arxiv_id":"2607.21021","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Multimmit achieves ~2δ faster expected ordering than Raptr by letting votes attest fresh blocks beyond the leader's proposal, while a faulty producer can only delay its own chain.","lead":"Multimmit is a blockchain consensus protocol that combines one-round finality with parallel per-producer transaction chains and extension votes, ordering honest blocks roughly two message delays earlier than the state-of-the-art Raptr. Its formal guarantees localize damage from faulty producers to their own chain and give a leader-independent block-inclusion theorem.","discovery_kind":"new_method","skeptic_critique":null,"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":1424,"tokens_out":1356,"duration_ms":403523,"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":[{"comment":"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.","section":"Sections 7–8 (and end of Section 6)"},{"comment":"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.","section":"§3.6 and §5.2"},{"comment":"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.","section":"§2 and §5.2 (Lemma 12)"}],"minor_comments":[{"comment":"'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.","section":"§1.1"},{"comment":"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.","section":"§3.8"},{"comment":"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.","section":"§3.4 vs §4"},{"comment":"The figure/caption combination is hard to parse in text; a clearer diagram with labelled frontiers would help.","section":"Figure 3"},{"comment":"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.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The paper is clearly a draft: two sections are placeholders and the central latency claim lacks a formal proof. The core safety and liveness proofs appear sound on inspection, and the block-inclusion theorem is a nice result, so I think the paper is salvageable. The authors should be asked to formalise the latency analysis (or soften the claims), integrate or explicitly scope the retrieval mechanism, and complete the missing sections before the paper is sent for further review."},"author_rebuttal":null,"desk_editor":null,"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["blockchain consensus","state machine replication","Byzantine fault tolerance","multi-chain data dissemination","finality latency","partial synchrony","extractable SMR","censorship resistance"],"falsifier":"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.","tokens_in":48862,"feed_emoji":"⛓️","tokens_out":5729,"duration_ms":59973,"temperature":0.7,"pith_summary":"The paper introduces Multimmit, a blockchain consensus protocol that combines a one-vote-per-view consensus layer with per-producer chains of transaction blocks. Its central claim is that a transaction block broadcast at time t is placed in the total order by t+3δ in expectation and t+2δ at best, measured from the block's own dissemination rather than from the leader's proposal. The paper argues this is faster than previous designs by roughly two message delays, and that the speed holds even when non-leader processors are faulty: a faulty producer can delay only its own chain's blocks, so there is no way for a minority to spoil the fast path for everyone. It also proves a censorship-resistance guarantee: no leader can finalise its own block while excluding a fresh, well-circulated block from an honest chain. The protocol solves Extractable SMR, meaning block data is guaranteed retrievable but the actual retrieval mechanism is left as an implementation detail.","feed_headline":"Three message delays to finality—and no minority can spoil it","feed_subtitle":"Votes carry fresh blocks past the leader's proposal, saving two message delays and confining faults to the faulty producer's own chain.","key_machinery":"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","core_discovery":"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","pith_inferences":["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."],"forward_implications":["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."],"fun_headline_variants":["Votes carry fresh blocks: finality in two message delays","Multimmit: parallel SMR with fault-isolated finality","Faster finality without leader data bottleneck","No minority can block finality: Multimmit's vote-carried blocks"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Votes carry fresh blocks: finality in two message delays","Multimmit: parallel SMR with fault-isolated finality","Faster finality without leader data bottleneck","No minority can block finality: Multimmit's vote-carried blocks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000581,"raw_usage":{"total_tokens":2634,"prompt_tokens":870,"completion_tokens":1764,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":614,"completion_tokens_details":{"reasoning_tokens":1693}},"tokens_in":614,"tokens_out":1764,"duration_ms":13187,"temperature":1.0,"reasoning_tokens":1693,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T03:33:17.976301+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":2}