{"id":"8ccb413d-67a0-40e4-b9a8-895d2f38e338","arxiv_id":"2511.15517","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Beluga gives BFT consensus a principled block synchronizer with admission control and implicit availability proofs, preserving optimistic latency and bounding pull-based attacks.","lead":"This paper defines the block-synchronizer layer of BFT consensus and presents Beluga, which keeps fast-path performance while bounding recovery through reputation-based admission control and implicit availability proofs. Beluga is deployed in Sui and reported to raise throughput 3-fold and cut latency 25-fold under a 'pull induction' attack in AWS tests.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Theorem 5's 'nearly 2Δ' latency bound relies on Assumption 1 (Latency Triangle); without it, honest validators can be falsely blamed and excluded from parent selection, so the headline adverse-case guarantee is unsupported under the paper's stated partial-synchrony model.","rationale":"I agree with the reader's selection of Assumption 1 as the weakest assumption. The paper is honest enough to state the limitation in Appendix A and to note that correctness does not rely on it, but the abstract's performance claims and the '~2Δ' entry in Table 1 are not qualified by this assumption. The concrete mechanism I describe—false blame of an honest validator leading to reputation-based exclusion and worse-than-2Δ latency—follows directly from the protocol's definitions in Figure 8 (lines 23-32) and the admission control (lines 14-17). The dimensional error in Theorem 5's proof (the term (R_m−R_h)f/(2ΔR_L^2)) further indicates that the adverse-case analysis is not yet a rigorous derivation. For these reasons, the reader's CONDITIONAL verdict is appropriate: the central design insight (ImPoA, hybrid pull, AC) is plausible and supported by the open-source implementation and production adoption, but the headline performance theorem should be restated as conditional on the Latency Triangle assumption, or the proof should be extended to a wider class of network models. The proposed simulation test would settle whether the concern lands, and if it does, the paper's contribution remains but with a materially narrower performance guarantee.","tokens_in":26567,"tokens_out":12483,"duration_ms":126078,"concrete_test":"Use the open-source Beluga simulator (commit 9a3d2a3) to run a 7-validator WAN topology that violates Assumption 1: set direct latency A–C = 200 ms while A–B = B–C = 50 ms (B honest), with one Byzantine validator executing the pull-induction attack. Instrument each honest validator to log (i) pull requests triggered for blocks created by other honest validators, (ii) reputation changes of honest validators, and (iii) round-to-round latency. If any honest validator receives ≥f+1 reports, its reputation drops by R_L, and the measured round latency exceeds 2Δ, then Theorem 5 fails without Assumption 1. If no false blame occurs (e.g., because pulls are suppressed for direct arrivals), the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The most load-bearing concern is the dependence of the headline adverse-case performance claim on Assumption 1 (Latency Triangle), stated only in Appendix A. Theorem 5 ('nearly 2Δ' round latency) and Lemma 3 ('honest validators never blamed') presuppose that after GST the direct latency between two honest validators is always smaller than the latency through any intermediate validator. Assumption 1 is not part of the standard partial-synchrony model, and the paper explicitly notes correctness does not rely on it—yet the abstract claims 'bounding the cost of recovery' and Table 1 cites '~2Δ' adverse latency. If the assumption fails (e.g., a congested direct link is slower than a two-hop route), an honest validator v_j can receive a block referencing v_i's block before v_i's direct message, triggering a live pull and a 'report' against v_i. Once f+1 honest validators issue such false reports, v_i's reputation drops by R_L and the admission control excludes v_i from parent selection. Since every honest block needs 2f+1 parents, excluding one honest validator can leave fewer than 2f+1 acceptable honest parents, forcing honest validators to reference adversary-controlled blocks and incur repeated pulls, pushing round latency above 2Δ. The proof's final formula contains a dimensional error ((R_m−R_h)f/(2ΔR_L^2) mixes time and dimensionless quantities), which is symptomatic of the sketch-level case analysis. The concern is not about internal inconsistency of the protocol; it is that the central performance theorem is conditional on an unstated network assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces the block synchronizer abstraction for BFT consensus protocols, specifies desirable goals (G1 eventual availability, G2 optimistic push latency, G3 bounded amplification), identifies a 'pull induction attack' against existing best-effort push/random-pull synchronizers, and presents Beluga, a synchronizer combining an admission-control mechanism based on validator reputation, an optimistic best-effort push, and a hybrid pull protocol that separates live (latency-critical) pulls from bulk (background) pulls using an Implicit Proof-of-Availability (ImPoA) scheme. The authors prove (or sketch proofs) that Beluga satisfies the block-synchronizer properties, claim an average adverse-case round latency approaching 2Δ, and report an implementation integrated into Mysticeti/Sui with AWS experiments showing up to 3× throughput and 25× latency improvements over baseline under the pull induction attack, plus a production deployment on Sui mainnet.","tokens_in":26961,"tokens_out":8836,"duration_ms":80584,"significance":"If the claims are made rigorous, the paper addresses a real and practically important gap: the block-dissemination layer of high-throughput DAG-based BFT protocols is often ad hoc, and the pull induction attack is plausible in deployed systems. Beluga's design ideas—reputation-based admission control, ImPoA to pull off the push path, and the live/bulk distinction—are clever and have been validated in production, which is a meaningful strength. The paper also contributes a clear problem formulation and a comparative table of synchronizer properties. However, the theoretical performance guarantee is the paper's central advertised contribution, and it currently rests on an auxiliary assumption (the Latency Triangle), a dimensional error in the final formula, and an unquantified random-pull amplification bound. The empirical results and the production deployment are valuable, but the analytical claims need to be corrected and restated before the paper can be accepted as a rigorous treatment of bounded-amplification synchronization.","major_comments":[{"comment":"The headline adverse-case claim ('nearly 2Δ' round latency) and Lemma 3 ('honest validators never blamed') rely on Assumption 1 (Latency Triangle), which is introduced only in Appendix A and is not part of the standard partial-synchrony model stated in Sec. 2. Under the stated model, after GST the adversary controls message ordering; it can deliver a block that references an honest validator v_i's block before v_i's direct message reaches v_j. This causes v_j to pull and report v_i. If f+1 honest validators issue such reports, v_i's reputation drops by R_L and admission control may exclude v_i from parent selection, forcing honest proposers to reference adversary-controlled blocks and inducing further pulls. Thus Lemma 3 is false without Assumption 1, and the Theorem 5 bound is not supported in the paper's own network model. The paper notes that correctness does not rely on Assumption 1,","section":"Appendix A, proof of Theorem 5"},{"comment":"The displayed bound at the end of the proof of Theorem 5 is dimensionally inconsistent. The expression is 2Δ(1 + (3+2f)/(2R_L) + (R_m−R_n)f/(2Δ R_L^2)). The second term is dimensionless, while the third term has units 1/Δ if R_m, R_n, R_L are dimensionless reputation scores. Tracing back, |D_2| = (R_m−R_h)f/R_L is a number of rounds, so the extra latency it contributes is |D_2|·2Δ = 2Δ(R_m−R_h)f/R_L, and dividing by R_L rounds gives a term 2Δ(R_m−R_h)f/R_L^2, not a term with Δ in the denominator. The formula as written cannot be evaluated and indicates a unit error in the case analysis. Please correct the algebra and define all quantities with units.","section":"Appendix A, proof of Theorem 5"},{"comment":"The bounded-amplification guarantee (G3) is not rigorously established. For bulk blocks, a validator chooses a provider uniformly at random and retries after timeout Δ_bk if it receives no response. The paper repeatedly uses 'eventually' (e.g., in Theorems 2 and 4) and 'within 2Δ' (e.g., in Lemmas 1 and 2) for this random pull, but no deterministic bound on the number of retries is given. In the worst case, the randomly chosen validator may never be one that stores the block, so the number of pull requests is unbounded. If the intended guarantee is 'with probability 1' or 'in expectation', that should be stated precisely and the theorems should be quantified accordingly. Alternatively, a deterministic fallback (e.g., after O(1) random tries, pull from all validators) would make the amplification bound clean. As written, the proof sketch does not establish G3 under adversarial scheduling.","section":"Sec. 4.3.2 / Sec. 1 G3"},{"comment":"Theorem 5 is stated as 'Beluga can achieve a round latency of nearly 2Δ under adverse cases,' but the proof in Appendix A establishes only an average over a window of R_L rounds (Lemma 7). Lemma 5 explicitly allows some rounds to have latency 3Δ, and Lemma 6 shows an average of 2Δ over a pair of rounds. The abstract and Table 1 present the adverse-case latency as '~2Δ' without this caveat. Please state the precise quantification: is the bound per-round, expected per-round, or a long-run average? If the bound is average-only, say so in the theorem statement and in Table 1, and make clear that an adversary can still cause occasional rounds at 3Δ.","section":"Sec. 5.2 / Table 1"}],"minor_comments":[{"comment":"The rows labeled 'Beluga' under each existing protocol are easy to misread as a separate synchronizer rather than the same Beluga module integrated with that consensus protocol. Consider using an explicit column 'Synchronizer protocol' with entries like 'Beluga (over Multi-chain)'.","section":"Table 1"},{"comment":"The statement 'a validator references B only if it (i) receives B, and (ii) can verify the availability of B's causal history (lines 4-5, Figure 8)' points to the wrong lines. Lines 4-5 of Figure 8 assign B.parents and B.weaklinks; the 'acceptable' condition is defined in the AC parent selection procedure (line 15). Please fix the pointer.","section":"Sec. 4.3.1 and Figure 8"},{"comment":"Assumption 1 is used to prove a main theorem but appears only in Appendix A. State it in Sec. 2 or at the start of Sec. 5.2 so the reader knows the adverse-case performance claim is conditional on this assumption.","section":"Sec. 2"},{"comment":"The phrase 'we empirically uncover the same implicit two-phase pattern' is not backed by a description of the empirical methodology in the main text. The paper cites codebases, but no systematic study is described. Please add a sentence explaining the methodology or refer to a separate artifact.","section":"Sec. 1"},{"comment":"Round-Progression says 'at least 2f+1 validators (not necessarily honest)' but Theorem 3's proof shows all honest validators progress. Make the definition consistent with the proof, or clarify that honest progress implies the definition.","section":"Sec. 2.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is from an experienced industrial group with a production deployment, which lends credibility to the empirical results. The main risk is that the theoretical performance bound—central to the paper's positioning—is not rigorous as written. The Assumption 1 dependence is particularly important because the standard partial-synchrony model does not include any latency-triangle guarantee, and the final formula has a clear dimensional error. These are fixable, but they require a substantive rewrite of the analysis, not just copy-editing. I recommend major revision and suggest the reviewers ask for a corrected and fully quantified version of Lemma 7 and Theorem 5, with Assumption 1 stated as a hypothesis if it cannot be removed."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: Beluga is a serious systems paper with a genuinely useful abstraction and a real deployment, but the headline '~2Δ adverse-case round latency' is conditional on an assumption the abstract doesn't mention, and the proof as written has a dimensional error. The core design is still sound and the paper deserves a real referee.\n\nWhat's new: the block-synchronizer abstraction is a good way to talk about the push-pull glue that every high-throughput BFT stack actually has. The ImPoA mechanism — using f+1 references from later rounds as implicit availability evidence — is a neat idea that credibly separates live pulls from bulk recovery. Naming the pull induction attack is useful even if the underlying withholding behavior is familiar; formalizing it as a class helps structure the design space. The paper also ships a commit-pinned implementation, reports a production adoption on Sui, and shows large under-attack improvements over their baseline. That's real evidence and should be credited.\n\nWhere it's soft: Theorem 5's near-2Δ bound is the main advertised performance claim, and it depends on Assumption 1 (Latency Triangle) in Appendix A. That assumption is not in the abstract and is not part of the standard partial-synchrony model. Without it, Lemma 3 fails: an honest validator with a slow direct link can receive another honest block via a relay first, trigger a pull, accumulate f+1 reports, and get its reputation cut enough to be excluded from parent selection. Since honest blocks need 2f+1 parents, excluding one honest validator can force references to adversary blocks and reintroduce the exact latency the theorem promises to bound. The paper does say correctness doesn't rely on the assumption — that's accurate and important — but the abstract's 'bounding the cost of recovery' and Table 1's ~2Δ entries are performance claims, and those do rely on it.\n\nAlso, the proof itself is a sketch. The final formula mixes dimensions: (R_m−R_h)f/(2ΔR_L^2) has units 1/time next to dimensionless terms. That's fixable, but it signals the case analysis isn't tight. G3's 'bounded amplification' is only argued in expectation for the random bulk pull; there's no deterministic bound on retries, which is a gap if G3 is stated categorically. The correctness theorems are also induction sketches rather than machine-checked or fully detailed proofs. The evaluation has no error bars and appears to be single-run, which is typical but still limits confidence. None of these are load-bearing enough to kill the paper — the design is plausible and the empirical direction is clear — but they are exactly what a referee should push on.\n\nWho should read it: anyone working on DAG-based BFT or on making reliable-broadcast guarantees practical. It will be a useful reference for the abstraction and the attack. I'd send it to peer review with a request for a tightened proof, an explicit statement of Assumption 1 in the abstract or a weaker bound without it, and a reproducible evaluation with variance.","headline":"A genuinely useful synchronizer abstraction and a real deployment, but the headline adverse-case latency bound depends on an unstated Latency Triangle assumption and a proof with a dimensional error.","tokens_in":27450,"tokens_out":3219,"would_cite":true,"duration_ms":30569,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["68M14","68M15"],"pacs":[],"model":"deepseek-v4-flash","headline":"Beluga frames block synchronization as a first-class BFT module and proves it can keep optimistic latency while bounding adversarial recovery cost.","keywords":["block synchronizer","BFT consensus","reliable broadcast","pull induction attack","DAG-based protocols","admission control","reputation mechanism","blockchain"],"falsifier":"Run a 10-validator Beluga deployment with three Byzantine validators that each round share blocks with exactly one honest validator (the Sec. 3.1 pattern) and measure per-round latency; the paper predicts it converges to near 2Δ after stabilization. Alternatively, construct a network where honest pairwise paths are consistently slower than a two-hop relay through an honest intermediate (violating the Latency Triangle) and check whether an honest validator's reputation drops and round latency exceeds 2Δ.","tokens_in":26448,"feed_emoji":"⚡","tokens_out":5069,"duration_ms":49118,"temperature":0.7,"pith_summary":"The paper argues that the push-pull block-exchange layer under modern high-throughput BFT consensus is not a minor implementation detail but a formal component — the block synchronizer — with three requirements: every block must eventually be retrievable (G1), optimistic-path push latency must stay at the network delay δ (G2), and recovery traffic must remain bounded even when the adversary schedules message delivery (G3). It exhibits a new attack, the pull induction attack, that exploits unstructured push-pull designs to force honest validators into redundant pulls, stalling rounds. Beluga is the paper's instantiation: an admission-controlled push phase plus a hybrid pull phase that separates 'live' pulls (deterministic, latency-critical) from 'bulk' pulls (random, bandwidth-cheap), using an implicit proof-of-availability to accept blocks even when ancestors are temporarily missing. If the claims hold, any DAG-based BFT protocol can gain robust recovery without sacrificing happy-path speed, and real deployments can shake off targeted latency attacks.","feed_headline":"Beluga: block synchronizer keeps BFT fast even under attack","feed_subtitle":"Sui runs it in production; under pull-induction attacks, throughput rises 3x and latency drops 25x.","key_machinery":"The ImPoA mechanism is the load-bearing object: a block is implicitly available when at least f+1 subsequent blocks (strong or weak links) reference it, which constitutes an implicit certificate of causal availability. Around it sit the admission-control push (reputation table with asymmetric decreases, parent selection of the top 2f+1 reputations) and the hybrid pull (deterministic pulls for live blocks on the critical path, randomized pulls for bulk blocks off the critical path). Together they keep pushes at one network delay while bounding pull amplification.","core_discovery":"Beluga claims to be the first block synchronizer simultaneously satisfying G1, G2, G3: eventual availability of every accepted block, optimal δ push latency in the optimistic case, and bounded amplification under adversarial scheduling. The design builds a DAG in which validators reference parents chosen by admission control based on reputation, and it adds weak links, watermarks, and ancestor arrays so that a block is treated as 'implicitly available' once f+1 later blocks reference it. That implicit proof of availability lets validators accept live blocks without waiting for unavailable ancestors, moving missing data off the critical path. The paper proves round latency δ in happy cases an","pith_inferences":["The reputation asymmetry (small increases, huge decreases) effectively makes the system game-theoretically stable against rational Byzantine validators: the cost of staging a pull-induction delay exceeds any plausible benefit, so the protocol may push even rational adversaries toward honest dissemination.","If the Latency Triangle assumption fails in real networks — e.g., under network-level routing manipulation or when an intermediate validator has a faster link than the direct pairwise path — the 'nearly 2Δ' guarantee could degrade; an adversarial relay could make honest validators appear slow and trigger the blame mechanism. This is an editorial implication, not stated in the paper.","The same ImPoA idea could be ported to leader-based (PBFT-style) protocols: replacing explicit certificates with implicit availability from later references might cut the two-round certificate overhead while preserving totality guarantees.","A concrete testable extension is to instrument Beluga with a tunable reputation-decrease constant RL and measure the observed worst-case round latency versus the bound's 1/RL dependence; the paper's Theorem 5 predicts a specific quantitative relation."],"forward_implications":["Mysticeti-style uncertified DAG protocols can keep their δ happy-path latency while gaining the bounded-recovery guarantee they previously lacked.","The pull induction attack, which the paper measures as up to 50x latency inflation and 15x throughput loss on existing systems, is neutralized: admission control stops low-reputation blocks from entering the DAG as parents.","Any BFT consensus protocol that can apply its ordering rules to RBC patterns in the DAG can adopt Beluga as a drop-in dissemination layer without altering safety logic.","Production blockchains can expect tail-latency stability under network degradation; the Sui deployment reports a 5x reduction in 95th-percentile latency under attack.","The block synchronizer abstraction gives protocol designers a single module to specify, verify, and tune for data dissemination, separating it from the safety-critical ordering core."],"fun_headline_variants":["Beluga: block sync beats pull attacks with 3x throughput","Beluga syncs blocks without the bandwidth bomb","Beluga: 25x lower latency under adversarial pulls","Beluga block sync: optimal latency, bounded amplification","Beluga: first block synchronizer with proof of availability"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"Theorem 5's nearly-2Δ adverse-case latency relies on Assumption 1 (Latency Triangle): after GST, direct communication between any two honest validators is always faster than relaying through a third validator; if that fails, an honest validator can appear slow, get blamed, and the performance guarantee weakens (correctness itself does not depend on this).","fun_headline_variants_meta":{"raw":{"variants":["Beluga: block sync beats pull attacks with 3x throughput","Beluga syncs blocks without the bandwidth bomb","Beluga: 25x lower latency under adversarial pulls","Beluga block sync: optimal latency, bounded amplification","Beluga: first block synchronizer with proof of availability"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000704,"raw_usage":{"total_tokens":3003,"prompt_tokens":725,"completion_tokens":2278,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":469,"completion_tokens_details":{"reasoning_tokens":2212}},"tokens_in":469,"tokens_out":2278,"duration_ms":15045,"temperature":1.0,"reasoning_tokens":2212,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-03T21:22:29.602892+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a 10-validator Beluga deployment with three Byzantine validators that each round share blocks with exactly one honest validator (the Sec. 3.1 pattern) and measure per-round latency; the paper predicts it converges to near 2Δ after stabilization. Alternatively, construct a network where honest pairwise paths are consistently slower than a two-hop relay through an honest intermediate (violating the Latency Triangle) and check whether an honest validator's reputation drops and round latency exceeds 2Δ.","supporting_citations":[],"review_version":1}