{"id":"ddbf3545-2463-4c4d-bc22-3a91f476a009","arxiv_id":"2412.16774","paper_version":1,"verdict":"REJECT","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"high","formal_verification":"none","parameter_count":5,"one_line_summary":"The paper presents an unvalidated proposal to use DDPG-based leader election inside Raft consensus for edge computing task sharing, with no experimental evidence.","lead":"This paper proposes a system that combines Raft consensus, blockchain, and a Deep Deterministic Policy Gradient (DDPG) agent to elect edge nodes for task execution in Multi-access Edge Computing. The authors claim this reduces latency and prevents task loss, but they provide no implemented results, code, or data to support the claim.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The DDPG model is never coupled to Raft's leader-election mechanism: no state/action/reward mapping or policy-to-timeout rule is defined, so the claimed latency optimization is not a well-formed claim and its safety and liveness cannot be assessed.","rationale":"I agree with the reader's rejection, but I locate the core weakness one step earlier than the reader's weakest_assumption. The reader focuses on whether a learned policy preserves Raft's safety and liveness; that question presupposes a well-defined policy-to-election mapping. The manuscript never provides that mapping: Algorithm 1 is a generic DDPG loop whose state, action, reward, and transition are all unspecified in Raft terms. Consequently the claimed latency improvement is not merely unvalidated; it is not a well-defined empirical prediction. This is an internal coherence problem, not a disagreement with any field consensus. The missing figures (Fig. 1/2) and placeholder equations (e.g., 'ADDD EQ 1 HERE') reinforce the incompleteness but are secondary. The concrete test above would force the authors to either specify the integration and demonstrate safety/latency, or reveal that no such integration exists in the current proposal. Since the reader already recommends REJECT with high confidence, my analysis leaves that verdict unchanged.","tokens_in":11081,"tokens_out":4558,"duration_ms":40965,"concrete_test":"Require an explicit MDP instantiation: state must encode per-node resourcefulness, current term, and heartbeat freshness; action must be a deterministic transformation of election timeout (or vote decision); reward must equal the negative of total latency in Eqs. (1)+(2)+(5); transition must be the Raft state machine under message delays. Then implement Algorithm 1 on a discrete-event Raft simulator with N=5, crash/partition faults, and run at least 1000 terms. The concern lands if either (a) the MDP cannot be instantiated without adding unlisted assumptions, or (b) simulation shows a term with zero or multiple leaders, or an election fails to terminate, or (c) median latency is not below randomized-election Raft.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim (Section I: 'DDPG assists the raft protocol by allowing it to elect the most resourceful node in the cluster as its leader') requires a concrete mechanism by which the learned policy changes Raft's election. Section V and Algorithm 1 define a generic DDPG loop, but none of its components reference Raft semantics: the state S0={0,...,0} is not specified in terms of node resources or Raft state; the action A is a continuous Gaussian sample with no defined effect on election timeouts, terms, or vote requests; the reward R is not tied to the latency equations (1)-(5); and the transition f(S,A) is left as an unspecified function. Because this mapping is absent, the paper does not actually define a DDPG-based leader-election algorithm; it defines an RL training loop and asserts a connection. Moreover, even if the mapping were supplied, replacing Raft's randomized timeout (Section III-A) with a learned policy would require showing that the policy preserves at-least-one-vote-per-term and majority-election properties under partial synchrony; no such analysis or simulation appears. The claim therefore rests on an unstated, unspecified assumption.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes combining the Raft consensus algorithm with a Hyperledger Fabric-based multi-access edge computing (MEC) system for task sharing, and claims that a Deep Deterministic Policy Gradient (DDPG) agent can optimize the system by electing the most resourceful edge node as the Raft leader, thereby reducing overall latency. The manuscript reviews Raft background, introduces a latency decomposition in Section IV (migration latency, block-generation latency, and block-consensus latency), and then presents a DDPG training loop in Section V. The central claim, however, is never made precise: the state, action, reward, and transition function of the DDPG agent are not connected to Raft's election mechanism, and the results section refers to figures and empirical comparisons that are not present in the manuscript. The paper therefore does not currently provide a well-defined DDPG-based leader-election algorithm, nor evidence that such an algorithm would reduce latency or preserve Raft's safety and liveness.","tokens_in":11504,"tokens_out":4272,"duration_ms":38185,"significance":"If the paper had supplied a concrete mapping from DDPG state/action/reward to Raft leader election, together with a correctness argument that the learned policy preserves Raft's election safety and liveness, and an experimental comparison showing lower latency than randomized Raft election, the result would be a useful contribution to MEC resource sharing and blockchain-based edge systems. The manuscript does provide a readable summary of Raft and a plausible latency decomposition in Eqs. (1)-(5), which are useful background. However, the proposed DDPG contribution is not defined as an algorithm, and the reported results consist of absent figures and unquantified claims. As submitted, the central claim is unsupported, so the significance of the work cannot be assessed on the basis of the manuscript.","major_comments":[{"comment":"The paper never defines the mapping from DDPG to Raft leader election. The initial state S0 = {0,...,0} is not specified in terms of node resources, Raft state, or the latency equations; the action A is sampled from a Gaussian distribution with no stated effect on election timeout, term number, or vote requests; the reward R is never defined; and the transition function f(S,A) in Eq. (8) is left as an unspecified function. Consequently, the claim in Section I that DDPG 'allows it to elect the most resourceful node in the cluster as its leader' is not a well-formed algorithmic claim. The authors need to define the state features, action semantics, reward, and transition in terms of the Raft protocol and Eqs. (1)-(5).","section":"Section V-A and Algorithm 1"},{"comment":"Replacing Raft's randomized election timeout with a learned policy must preserve Raft's Election Safety (at most one leader per term) and Liveness (eventual leader election), as established in Ongaro and Ousterhout [24]. The manuscript provides no invariant, no proof, and no simulation showing that a DDPG-learned policy under partial synchrony satisfies these properties. Without such an argument, the proposed system's correctness is unverified, and the claim that the system improves reliability and avoids task failure is unsupported.","section":"Section III-A and Section I"},{"comment":"The Results subsection claims that Fig. 1 and Fig. 2 show average reward per trial and reward per episode, and that the training and testing yielded low standard deviations and maximized reward values. However, no figures, numerical latency values, baseline comparisons with standard Raft, confidence intervals, or error analyses are present in the manuscript. The conclusion in Section VI that 'through the DDPG model, we have optimized our proposed system' is therefore not supported by any empirical evidence.","section":"Section V-D"},{"comment":"The parameter roles of θ and ψ are inconsistent. Table I identifies θ as parameters from the actor network and ψ as parameters from the critic network, but Eq. (11) updates θ with the critic loss ∇L, Eq. (12) computes the actor gradient as ∂Q/∂ψ, and Eq. (6) writes A = π(S | ψ). The text also mentions learning rates α1 and α2 without clearly assigning them to actor or critic. These inconsistencies make the training procedure irreproducible as written.","section":"Equations (11)-(13) and Table I"},{"comment":"The DDPG optimization objective is never tied to the latency model. The reward R is not derived from Eqs. (1)-(5), and the optimization problem in Section V is not stated as minimizing τ_TML, τ_CLBG, or τ_RCB. As a result, even if the DDPG loop were well defined, there is no reason to believe that maximizing the implicit reward corresponds to reducing overall system latency, which is the paper's central claim.","section":"Section V and Section IV"}],"minor_comments":[{"comment":"The manuscript contains placeholder text such as '(Fig coming soon)' and '(ADDD EQ 1 HERE)', which indicates that the paper is incomplete and needs to be finished before review.","section":"Section IV"},{"comment":"The symbol table defines τ_TML with |Zl(τ)|, but Eq. (1) uses |Zl(Γ)|; the notation should be made consistent.","section":"Table I and Eq. (1)"},{"comment":"The text contains the typo 'DDGP' and an extended analogy about commuting from work to home that is out of place in a technical results section.","section":"Section V-D"},{"comment":"The number of epochs is inconsistent: Section V-D states 100 epochs and 500 episodes, while Section V-A mentions '500 epochs in this paper' and Algorithm 1 uses Γ_max as the maximum iterations.","section":"Section V-A and Section V-D"},{"comment":"The phrase 'term leader N from the n-th cluster' is unclear, and the auction-theory and game-theory concepts mentioned in the abstract and index terms are never developed in the body of the paper.","section":"Section IV"}],"recommendation":"reject","confidential_remarks":"The manuscript appears to be an incomplete draft: it contains placeholder text, missing figures, undefined reward/state/action semantics, and no experimental results. The central contribution, DDPG-based Raft leader election, is not actually specified as an algorithm, and the safety/liveness implications of replacing Raft's randomized election are not addressed. These are load-bearing issues that cannot be resolved by minor revision; a substantial rewrite with a concrete mechanism and evaluation would be required."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is an incomplete draft, not a paper. The core claim—that DDPG lets Raft elect the most resourceful node as leader and thereby reduces latency—is never actually specified. The DDPG section and Algorithm 1 are a generic RL training loop: state S0={0,...,0}, action A from a Gaussian, transition S_{Γ+1}=f(S,A), and reward R are all undefined in terms of Raft terms, timeouts, vote requests, or the latency equations (1)-(5). Nothing in the algorithm changes Raft's election mechanism. So the central claim is not well-formed; you cannot evaluate what is being optimized.\n\nWhat the paper does reasonably: the Raft background in Section III is mostly accurate, and the latency model in Section IV (migration, block generation, consensus communication) is a plausible starting point. The idea of steering leader election with RL is not crazy and builds on prior work like Lu et al. and Figetakis and Refaey. The authors correctly identify the randomized election timeout as a place where latency enters.\n\nThe soft spots are large. The results section references Fig. 1 and Fig. 2, but the figures are absent and no numerical values, baselines, or error bars are given. Placeholder text remains (\"Fig coming soon\", \"ADDD EQ 1 HERE\"), and there are typos like \"[16]formance\". The paper never analyzes whether a learned election policy preserves Raft's safety (one leader per term) or liveness (eventual election) under partial synchrony; that is a load-bearing assumption, not a detail. The hyperparameter discussion is also inconsistent—500 epochs is stated in one place, 100 epochs in another.\n\nA heavy self-citation pattern is present, but several of those citations are actually relevant, so I would not flag it separately.\n\nBottom line: this is not ready for peer review. The missing coupling between DDPG and Raft is a conceptual gap, not an editorial issue, and the results section is empty. If the authors return with a defined state/action/reward mapping, a simulation comparing against vanilla Raft, and a correctness argument, this could become a workshop-level paper. As is, desk reject.","headline":"An incomplete early draft that asserts a DDPG-Raft combination for MEC but never defines how the two connect, and the results section has no data; not ready for any serious referee.","tokens_in":11857,"tokens_out":1642,"would_cite":false,"duration_ms":15449,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A DDPG-trained policy can choose Raft's leader to cut latency in edge-computing clusters.","keywords":["Raft consensus","Multi-access Edge Computing","DDPG","leader election","Hyperledger Fabric","latency optimization","reinforcement learning","blockchain"],"falsifier":"Run a multi-node cluster under the learned election policy in a partially synchronous network with injected message delays and a partitioned node; if the system ever records two leaders for the same term, or a term with no elected leader despite a majority of live nodes, the central claim is refuted. This can be checked by instrumenting Raft's RequestVotes and AppendEntries logs across many randomized network schedules.","tokens_in":1671,"feed_emoji":"⚡","tokens_out":1721,"duration_ms":52622,"temperature":0.7,"pith_summary":"The paper tries to establish that a Multi-access Edge Computing (MEC) cluster sharing tasks through a Raft-based private blockchain can reduce overall latency by replacing Raft's randomized leader election with a Deep Deterministic Policy Gradient (DDPG) agent that picks the most resourceful node as leader. It models the cluster as a Hyperledger Fabric network where shortlisted edge nodes run an election, and it derives equations for the three main latency sources: task migration from the cloud, block generation, and block-consensus communication. The DDPG actor-critic is trained to choose an action (effectively the leader choice) by maximizing reward over 500 episodes, with explicit action refinement through the critic's Q-function. The paper concludes that the trained policy yields low standard deviation and high reward values, which it interprets as an optimal policy gradient that improves the system's responsiveness.","feed_headline":"DDPG chooses the Raft leader to cut edge latency","feed_subtitle":"Replacing Raft's random timeout with a trained policy aims for lower edge task latency.","key_machinery":"The central object is Deep Deterministic Policy Gradient (DDPG), an actor-critic reinforcement learning method. The actor maps a state $S$ to a continuous action, exploration noise $g$ is added to collect experience, and the critic $Q(S, A)$ provides a value signal; target networks and soft updates stabilize training. The paper augments the standard algorithm with an explicit action-refinement step, $A^* = \\arg\\max_{\\tilde{A}\\in\\mathcal{A}} \\hat{Q}(S, \\tilde{A})$, and connects this to Raft's leader election so that the elected leader is, by training, the most resourceful node. This machinery replaces the randomized election timeout that normally drives Raft's leader election.","core_discovery":"The central claim is that a DDPG-based resource-training algorithm, when inserted into Raft's election step, elects the most resourceful edge node in the cluster as the leader and thereby lowers end-to-end task latency compared with conventional Raft's randomized election timeout. The proposed mechanism is an actor-critic loop: the actor network outputs a candidate action from a Gaussian-perturbed policy, the critic refines that action via $A^* = \\arg\\max_{\\tilde{A}\\in\\mathcal{A}} \\hat{Q}(S, \\tilde{A})$, and policy-gradient updates adjust the actor toward higher expected reward. Latency is quantified by three equations covering migration ($\\tau^{\\mathrm{TML}}_l$), block generation ($\\tau^{\\mathrm{CLBG}}_l$), and consensus over the wireless links ($\\tau^{\\mathrm{RCB}}_l$), and the DDPG objective is presented as optimizing those quantities. The paper reports training curves (average reward per trial) and moving averages as evidence that the learned policy is stable and improving.","pith_inferences":["The paper does not demonstrate that a learned election policy preserves Raft's safety and liveness; a direct test would be to run the learned policy under adversarial network delays and verify that no term ever has two leaders and that an election always terminates.","The auction-theory framing is left implicit; one could formalize leader election as a bid-based auction where each node's 'bid' is its predicted latency contribution, making the resource-optimality claim precise and testable.","The reported results are DDPG training curves (reward per episode), not end-to-end latency comparisons; a natural extension is to measure actual task latency with and without DDPG on the same cluster under identical traffic.","DDPG is normally designed for continuous control, while leader election is a discrete choice; implementing the paper's proposal in practice would require either a discrete-action variant or an explicit continuous relaxation, which the paper does not discuss."],"forward_implications":["If correct, Raft-based MEC clusters can replace randomized election timeouts with a resource-aware policy, lowering the expected latency of each task offload.","The leader elected by the DDPG policy should, on average, be the node with the best combination of compute speed, bandwidth, and channel quality, so task execution and block generation happen on the most capable node.","Because the policy is trained across episodes, the cluster could adapt to changing load without re-architecting the consensus protocol.","The explicit latency equations (migration, block generation, consensus) give a measurable target: a deployed system could monitor those quantities to verify the claimed improvement."],"supporting_citations":[{"why":"Supplies the Raft consensus algorithm, including leader election and log replication, which the proposed DDPG modification replaces.","marker":"[24]"},{"why":"Introduces partial synchrony, the network model that the paper's consensus guarantees implicitly rely on.","marker":"[20]"},{"why":"Provides performance analysis of Raft-based private blockchains, the system context being optimized.","marker":"[31]"},{"why":"Presents an intelligent transaction migration scheme for Raft-based private blockchains, a related optimization that this work extends.","marker":"[30]"},{"why":"Demonstrates deep reinforcement learning for MEC selection, the methodological basis for applying DDPG to edge node choices.","marker":"[34]"},{"why":"Cited as the source of the DDPG algorithm and its update rules for the actor-critic training.","marker":"[33]"},{"why":"Describes task sharing and scheduling on Hyperledger Fabric edge servers, the ledger architecture the proposed system adopts.","marker":"[9]"},{"why":"Explores consortium blockchain with MEC in a proof of concept, which the paper positions as prior work to extend.","marker":"[10]"}],"fun_headline_variants":["DDPG-tuned Raft elects resource-rich edge leader","Auction-based Raft with DDPG picks best edge node","Reinforcement learning improves Raft leader election for MEC","DDPG-driven Raft election cuts MEC task latency","Trained Raft election picks resourceful edge node for lower latency"],"cache_read_input_tokens":13952,"weakest_assumption_plain":"The load-bearing premise is that a machine-learned election policy still obeys Raft's rule of at most one leader per term and always eventually elects one, even when network delays are unpredictable.","fun_headline_variants_meta":{"raw":{"variants":["DDPG-tuned Raft elects resource-rich edge leader","Auction-based Raft with DDPG picks best edge node","Reinforcement learning improves Raft leader election for MEC","DDPG-driven Raft election cuts MEC task latency","Trained Raft election picks resourceful edge node for lower latency"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000447,"raw_usage":{"total_tokens":2300,"prompt_tokens":1029,"completion_tokens":1271,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":645,"completion_tokens_details":{"reasoning_tokens":1182}},"tokens_in":645,"tokens_out":1271,"duration_ms":7256,"temperature":1.0,"reasoning_tokens":1182,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T10:14:33.766648+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a multi-node cluster under the learned election policy in a partially synchronous network with injected message delays and a partitioned node; if the system ever records two leaders for the same term, or a term with no elected leader despite a majority of live nodes, the central claim is refuted. This can be checked by instrumenting Raft's RequestVotes and AppendEntries logs across many randomized network schedules.","supporting_citations":[{"cited_title":"In search of an understandable consensus algorithm,","cited_arxiv_id":null,"evidence_quote":"Supplies the Raft consensus algorithm, including leader election and log replication, which the proposed DDPG modification replaces."},{"cited_title":"Performance analysis of the raft con- sensus algorithm for private blockchains,","cited_arxiv_id":null,"evidence_quote":"Provides performance analysis of Raft-based private blockchains, the system context being optimized."},{"cited_title":"An intelligent transaction migration scheme for raft-based private blockchain in internet of things applications,","cited_arxiv_id":null,"evidence_quote":"Presents an intelligent transaction migration scheme for Raft-based private blockchains, a related optimization that this work extends."},{"cited_title":"Autonomous mec selection in federated next- gen networks via deep reinforcement learning,","cited_arxiv_id":null,"evidence_quote":"Demonstrates deep reinforcement learning for MEC selection, the methodological basis for applying DDPG to edge node choices."},{"cited_title":"Evolved prevention strategies for 6g networks through stochastic games and reinforcement learning,","cited_arxiv_id":null,"evidence_quote":"Cited as the source of the DDPG algorithm and its update rules for the actor-critic training."},{"cited_title":"Task sharing and scheduling for edge computing servers using hyperledger fabric blockchain,","cited_arxiv_id":null,"evidence_quote":"Describes task sharing and scheduling on Hyperledger Fabric edge servers, the ledger architecture the proposed system adopts."},{"cited_title":"Exploring the intersection of consortium blockchain technologies and multi-access edge computing: Chronicles of a proof of concept demo,","cited_arxiv_id":null,"evidence_quote":"Explores consortium blockchain with MEC in a proof of concept, which the paper positions as prior work to extend."}],"review_version":1}