{"id":"f11f84a5-5231-4c51-b6c9-c1e532f2ddb8","arxiv_id":"2506.14208","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":8,"one_line_summary":"The paper claims a closed-form optimal vehicle data extraction rate minimizes latency in a Raft-blockchain edge computing system, but the reported simulation optima contradict the derived formula.","lead":"This paper models delays in a blockchain-secured system where vehicles offload computing to roadside stations, and derives a formula for the data-sending rate that minimizes average delay. The simulation results reported in the paper do not match the formula's predictions with the stated parameters, so the validation is not convincing.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eq. (12) is not derived correctly and the paper's own Fig. 3 optima contradict Eq. (24), so the claimed closed-form minimum latency is not established.","rationale":"I agree with the reader's weakest_assumption: the collision probability in Eq. (12) is the linchpin of the paper. B = M(M-1)tau_c/2 enters the objective solely through the exponential e^{B*lambda}, and the closed-form optimum lambda* in Eq. (24) is obtained by setting the derivative of that objective to zero. If Eq. (12) is wrong, the optimum and the claimed convexity argument are unsupported. The paper contains no machine-checked proof, no reproducible code analysis here, and no independent dataset; the only apparent confirmation is Fig. 3, which reports optima (0.31, 0.23, 0.18) that disagree sharply with Eq. (24) under the Table 2 parameters (0.95, 0.53, 0.36). That mismatch is an internal inconsistency, not merely a modeling choice outside current consensus. A possible defense is that the simulation measures a different collision event than Eq. (12); the proposed Monte Carlo test would settle that. Because the central claim is the optimality of Eq. (24) and the evidence currently contradicts it, the reader's REJECT verdict should stand unchanged.","tokens_in":12298,"tokens_out":9983,"duration_ms":105157,"concrete_test":"Run an independent Monte Carlo simulation of M independent Poisson transmitters (rate lambda, plus constant encoding delay Tec) over a long horizon, sweeping lambda in [0.01, 2] for M = 2, 3, 4 with tau_c = 0.1. Record the empirical per-transmission collision probability pc(lambda) and the empirical argmin of E[T]. If the measured pc matches Eq. (12) and the argmin matches Eq. (24) within Monte Carlo error, the central claim survives; otherwise the collision term B and the closed-form lambda* are refuted.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The load-bearing step is the collision probability in Eq. (12), because B = M(M-1)tau_c/2 enters the optimum lambda* in Eq. (24) through the exponential term, and no other mechanism sets the optimal rate. Eq. (12) does not follow from Eq. (11): for two independent Exp(lambda) interarrival times, P(Tm1 - Tm2 > tau_c) = 0.5*exp(-lambda*tau_c), not exp(-lambda*tau_c), and the product over ordered pairs m1 != m2 double-counts unordered pairs. More basically, the no-collision event is not a product of pairwise tail probabilities: in M independent Poisson streams with rate lambda the superposition has rate M*lambda, so the probability that no pair of transmissions falls within tau_c obeys a different exponential law involving (M*lambda)^2*tau_c. The objective in Eq. (21) is convex only with this specific exponential form, so Eq. (24) inherits the error. The paper's own Fig. 3 makes the failure concrete: for M = 2, 3, 4 it reports optimal lambda values of about 0.31, 0.23, and 0.18, whereas Eq. (24) with Table 2 parameters gives about 0.95, 0.53, and 0.36. This internal inconsistency means the central claim is neither derived nor confirmed.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a security framework that integrates the Raft consensus mechanism with edge computing for Internet of Vehicles (IoV), models the expected system latency E[T] as a function of the vehicle data extraction rate λ, and derives a closed-form optimal rate λ* given by Eq. (24) via convex optimization. The paper claims that setting λ to λ* minimizes system latency, and presents simulations that it says confirm the theoretical optimum.","tokens_in":12635,"tokens_out":7785,"duration_ms":75757,"significance":"If the derivation were correct, the paper would offer a simple, closed-form rule for choosing a data extraction rate that minimizes latency in a blockchain-protected IoV edge computing system, which could be a useful engineering guideline for 5G and future networks. The paper has a clear system model and the algebraic minimization from the delay expression to Eq. (24) is internally consistent. However, the core collision probability model is not justified, and the reported simulation optima do not match the derived formula, so the central contribution is not currently established.","major_comments":[{"comment":"The collision probability derivation is incorrect and load-bearing. The event in Eq. (11) is defined over ordered pairs with Pr((Tm1 - Tm2) > τc). For two independent Exp(λ) inter-arrival times, this probability is 0.5 e^{-λ τc}, not e^{-λ τc}; multiplying over all ordered pairs would give M(M-1) factors, not the M(M-1)/2 that appears in Eq. (12). Moreover, the no-collision event for M vehicles is not the product of independent pairwise events: in a superposition of M Poisson streams of rate λ, collisions are governed by the total rate Mλ, and the probability that no two events fall within τc does not factor as a product of pairwise tail probabilities. Since B = M(M-1)τc/2 enters directly into the optimum λ* in Eq. (24), this error invalidates the main theoretical result.","section":"§5.2, Eqs. (11)-(12)"},{"comment":"The simulation results contradict Eq. (24). Using the Table 2 parameters (Tec = 10, τc = 0.1), Eq. (24) gives λ* ≈ 0.95 for M = 2, λ* ≈ 0.53 for M = 3, and λ* ≈ 0.36 for M = 4. The paper reports optimal points of 0.31, 0.23, and 0.18 for M = 2, 3, 4, respectively. This is a substantial discrepancy, and it means the statement that the curves 'align with our theoretical derivations' is not supported. The simulation does not validate the proposed formula.","section":"§6, Fig. 3"},{"comment":"The non-homogeneous Poisson process formulas are incorrect. The first-arrival time CDF should be P(T1 ≤ t1) = 1 − exp(−∫_0^{t1} Λ(x) dx), not 1 − exp(−∫_0^{t1} e^{−Λ(x)} dx). Similarly, Eq. (4) should condition on T1 = t1 and use ∫_{t1}^{t2} Λ(x) dx inside the exponential. These equations are not used later in the latency derivation, but they are presented as part of the system model and are mathematically wrong.","section":"§3.2, Eqs. (3)-(4)"}],"minor_comments":[{"comment":"The expression for Pp appears to contain a repeated term 'Q(η, ρη) − Q(η, ρη)' and the definition is unclear; the Bessel function J0 is introduced but does not appear in the expression.","section":"§5.1, Eq. (7)"},{"comment":"The 'real-time data extra algorithm' is essentially a single assignment (λ ← λ*) and does not describe how λ* is recomputed when N or M changes beyond a jump; the pseudocode is too trivial to be informative.","section":"§5.3, Algorithm 2"},{"comment":"The GitHub link provided in the introduction points to a repository named 'BVIB-for-Data-Extraction-Based-on-Mutual-Information-in-the-IoV', which appears unrelated to the present paper's topic of Raft-blockchain edge computing; this should be corrected or the link should be verified.","section":"Footnote 1"},{"comment":"There are several typographical and presentation issues, including 'V ANET' in Section 2, 'transmition' in Fig. 2, and the text in Section 5.3 referring to '−AE^{−Bλ}/((1−pd)λ^2)' as 'always non-zero' when the correct nonzero factor is A e^{Bλ}/((1−pd)λ^2); these should be corrected.","section":"Throughout"}],"recommendation":"reject","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"I'll cut to the chase: the closed-form lambda* is new, but it's built on a collision probability that isn't derived correctly, and the paper's own simulation results don't match the formula. The central claim—that setting the extraction rate to lambda* minimizes latency—is therefore not established.\n\nWhat the paper does well: it identifies a real problem, the added latency from Raft consensus in vehicular edge computing, and models the main delay components (extraction, collision, channel failure, decoding, leader election). The objective function in Eq. (21) is convex in lambda, and the minimization via Eqs. (22)-(24) is clean. The algebra from (20) to (24) checks out. Treating the data extraction rate as a tunable knob is a reasonable idea, and the paper is clearly written.\n\nThe soft spots are serious. Eq. (12) does not follow from Eq. (11). For two independent Exp(lambda) inter-arrival times, P(Tm1 - Tm2 > tau_c) = 0.5 e^{-lambda tau_c}, not e^{-lambda tau_c}, and the product over ordered pairs double-counts. The correct no-collision tail for M independent Poisson streams also has a different form. Since B = M(M-1)tau_c/2 enters directly into lambda*, this error is load-bearing. Separately, Eqs. (3)-(4), the non-homogeneous Poisson CDFs, are wrong (the exponent should be the integrated intensity, not the integral of e^{-Lambda(x)}). That's minor since the homogeneous case is used later. Most concerning, Fig. 3 reports optimal lambda around 0.31, 0.23, 0.18 for M=2,3,4, while Eq. (24) with Table 2 parameters gives roughly 0.95, 0.53, 0.36. The paper doesn't acknowledge this gap. The code link in the footnote points to a prior BVIB repository and isn't clearly the simulation code for this paper.\n\nThis is a subfield paper for researchers working on blockchain latency optimization in IoV. The topic is relevant, and the derivation is transparent enough to referee seriously, but the model and the validation both need major work. I would not accept it in current form; I'd send it back for revision with a request to fix the collision derivation and reconcile the simulation with the theory.","headline":"The claimed closed-form optimal extraction rate is new, but the model behind it is flawed and the simulation contradicts it.","tokens_in":13128,"tokens_out":4094,"would_cite":false,"duration_ms":39600,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A single closed-form extraction rate minimizes expected latency in Raft-blockchain edge computing for connected vehicles.","keywords":["Blockchain","Edge Computing","Internet of Vehicles","latency optimization","Raft consensus","data extraction rate","convex optimization","system delay"],"falsifier":"A discrete-event simulation of $M$ independent Poisson transmitters, each extracting at rate $\\lambda$ and retransmitting after a collision, can measure the collision probability directly and compare it with $1 - e^{-\\lambda M(M-1)\\tau_c/2$; the same simulation can find the empirical minimizer of expected delay and compare it with $\\lambda^*$ from Eq. (24) under the paper's Table 2 settings. If the measured collision curve or the measured optimum deviates from the formula, the claimed closed-form optimization is not confirmed.","tokens_in":12085,"feed_emoji":"🚗","tokens_out":9633,"duration_ms":97537,"temperature":0.7,"pith_summary":"This paper tries to show that securing vehicle edge computing with a Raft-consensus blockchain does not necessarily force a large latency penalty, because the expected end-to-end delay is a convex function of the rate at which vehicles extract data. The paper derives a closed-form optimal extraction rate $\\lambda^*$ that depends only on the number of vehicles served per base station and the collision timeout, not on the number of servers or how many are under attack. If the derivation is correct, a vehicle can set its extraction rate to $\\lambda^*$ and obtain the minimum expected system delay, and the same tuning rule can be updated online when the network configuration changes. This matters because blockchain security and ultra-low latency are usually in tension, and a simple rate rule would let both coexist.","feed_headline":"One formula sets the best data rate for secure vehicle networks","feed_subtitle":"Derived from a convex delay model, the optimum lambda balances extraction waiting against collisions and blockchain overhead.","key_machinery":"The load-bearing object is the exponential collision term $e^{B\\lambda}$ inside the delay expression. It comes from the collision probability $p_c = 1 - e^{-\\lambda M(M-1)\\tau_c/2}$, where $\\tau_c$ is the packet collision timeout and $B = M(M-1)\\tau_c/2$; this makes the expected number of retransmissions grow exponentially in $\\lambda$. Differentiating the convex delay function with respect to $\\lambda$ converts the minimization into solving the quadratic $BT_{ec}\\lambda^2 + B\\lambda - 1 = 0$, whose positive root is $\\lambda^*$.","core_discovery":"The paper's central claim is that the expected system delay in a Raft-blockchain edge computing network for the Internet of Vehicles is minimized by a closed-form vehicle data extraction rate. With $B = M(M-1)\\tau_c/2$, the delay takes the convex form $E[T] = \\frac{A}{1-p_d}\\left[\\left(T_{ec}+\\frac{1}{\\lambda}\\right)e^{B\\lambda} + T_{si}\\right]$, and its unique positive minimizer is $\\lambda^* = \\frac{-B+\\sqrt{B^2+4BT_{ec}}}{2BT_{ec}}$. The paper argues that this optimum is independent of the number of servers $N$ and of attack intensity $a$, which affect only the multiplicative prefactor $A$, so a vehicle can simply measure $M$ and set its extraction rate to $\\lambda^*$.","pith_inferences":["Going beyond the paper, the same convex-delay structure would generalize to other consensus mechanisms that impose a fixed per-epoch election overhead; only the expression for the expected election delay would change, not the quadratic form of the optimization.","A practical extension would make the tuning rule local: a base station broadcasts $M$ and $\\tau_c$, and each vehicle computes $\\lambda^*$ itself, avoiding the need for a centralized optimizer.","One could test whether adapting $\\lambda$ dynamically as $M$ changes during a drive-by scenario outperforms keeping a fixed rate, using the paper's delay formula as the performance baseline."],"forward_implications":["Setting each vehicle's data extraction rate to $\\lambda^*$ yields the minimum expected system delay for the given number of vehicles per station and collision timeout.","The optimal rate depends on $M$ but not on the number of servers $N$ or the attack intensity $a$, so the same per-station tuning rule remains optimal even as servers are attacked or added.","Because the delay function is convex, the optimum can be re-computed and applied online whenever the network configuration $M$ changes.","Latency rises steeply on both sides of $\\lambda^*$, since small rates inflate the extraction wait $1/\\lambda$ while large rates inflate collision-induced retransmissions.","The closed-form optimum gives network designers a direct latency floor for a given vehicle density, which can be compared against ultra-low-latency budget requirements."],"supporting_citations":[{"why":"Supplies the Raft consensus mechanism whose leader election and log replication delays the model incorporates.","marker":"[13]"},{"why":"Introduces the blockchain-enabled variational information bottleneck framework that this paper extends to Raft-based edge computing.","marker":"[27]"},{"why":"Provides the channel state transition probabilities used to model transmission success in the delay calculation.","marker":"[31]"},{"why":"Gives the channel discard probability formula that appears in the denominator of the delay expression.","marker":"[32]"},{"why":"Establishes communication delay as the quantity being modeled between vehicles and servers.","marker":"[28]"}],"fun_headline_variants":["A single formula finds the optimal data rate for secure vehicle networks","Closed-form delay minimizer sets ideal data rate for IoV edge security","One equation picks optimal data rate to beat blockchain latency","Mathematical formula hands vehicles the perfect data extraction rate","Closed-form optimum solves blockchain edge latency for connected cars"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The result rests on the assumed formula for how often vehicle transmissions collide, which treats each pair of vehicles' sending times as independent; if that collision formula is not exact, the optimal extraction rate changes.","fun_headline_variants_meta":{"raw":{"variants":["A single formula finds the optimal data rate for secure vehicle networks","Closed-form delay minimizer sets ideal data rate for IoV edge security","One equation picks optimal data rate to beat blockchain latency","Mathematical formula hands vehicles the perfect data extraction rate","Closed-form optimum solves blockchain edge latency for connected cars"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000598,"raw_usage":{"total_tokens":2783,"prompt_tokens":921,"completion_tokens":1862,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":537,"completion_tokens_details":{"reasoning_tokens":1780}},"tokens_in":537,"tokens_out":1862,"duration_ms":13194,"temperature":1.0,"reasoning_tokens":1780,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T00:19:49.722504+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A discrete-event simulation of $M$ independent Poisson transmitters, each extracting at rate $\\lambda$ and retransmitting after a collision, can measure the collision probability directly and compare it with $1 - e^{-\\lambda M(M-1)\\tau_c/2$; the same simulation can find the empirical minimizer of expected delay and compare it with $\\lambda^*$ from Eq. (24) under the paper's Table 2 settings. If the measured collision curve or the measured optimum deviates from the formula, the claimed closed-form optimization is not confirmed.","supporting_citations":[{"cited_title":"In search of an understandable consensus algorithm","cited_arxiv_id":null,"evidence_quote":"Supplies the Raft consensus mechanism whose leader election and log replication delays the model incorporates."},{"cited_title":"Blockchain-enabled variational information bottleneck for iot networks","cited_arxiv_id":null,"evidence_quote":"Introduces the blockchain-enabled variational information bottleneck framework that this paper extends to Raft-based edge computing."},{"cited_title":"Improving multipath TCP performance over wifi and cellular networks: An analytical approach","cited_arxiv_id":null,"evidence_quote":"Provides the channel state transition probabilities used to model transmission success in the delay calculation."},{"cited_title":"Federated learning with blockchain for autonomous vehicles: Analysis and design challenges","cited_arxiv_id":null,"evidence_quote":"Gives the channel discard probability formula that appears in the denominator of the delay expression."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes communication delay as the quantity being modeled between vehicles and servers."}],"review_version":1}