{"id":"dd02a431-f0ee-405a-9676-039cf9cfb73f","arxiv_id":"2502.15713","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A framework that couples transparent blockchain-hosted UAV relay selection with decentralized PPO-based multi-agent coordination for coverage and connectivity in IoV.","lead":"This paper combines blockchain-based relay selection with decentralized multi-agent reinforcement learning to manage UAV relays in Internet of Vehicles networks. It reports simulation results showing better relay quality and coverage versus centralized baselines, along with a smart-contract cost analysis.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Blockchain selection inherits unverified self-reported attributes and unverified off-chain QoU preferences; false reports can arbitrarily bias matching, so the claimed trusted selection and its QoU/QoV gains do not hold in the intended threat model.","rationale":"The reader's weakest assumption correctly targets the trust model: the smart contract trusts self-reported attributes without verification. I agree and sharpen it: the gap is not only unverified attributes; the QoU computation is performed off-chain by the vehicle, so even the submitted preference (which UAV is chosen) is unverifiable. The contract cannot ensure that the submitted proposal is the one maximizing QoU, nor can it detect inflated RB, AB, energy, or payment. Consequently, the 'transparent and trusted' selection mechanism delivers execution transparency but not data integrity, and the measured QoU/QoV advantages are conditional on honest reporting. This is load-bearing because the blockchain-hosted selection is one of the two advertised contributions (the other being MDRL coordination), and the matching produced by that selection directly feeds the coordination task. If a modest fraction of participants report falsely, the rankings and allocations are biased and the claimed improvements vanish. Other concerns are real but less load-bearing: the abstract's relay-stability claim is not directly measured in the evaluation; Figure 9 shows connectivity slightly below the static-placement baseline, so 'maximize connectivity' is overstated; the centralized DRL baseline is self-modified and may be undertrained for larger teams; and no error bars or code are provided. These issues weaken the strength of the conclusions but do not invalidate the coordination contribution. The trust/self-report issue, however, undermines the blockchain pillar that the title and contributions emphasize, and the simulations are silent on it. Since the issue is addressable by adding an off-chain verification or reputation-update mechanism and by evaluating adversarial robustness, conditional acceptance remains the appropriate verdict; my concern does not move the reader's verdict.","tokens_in":15,"tokens_out":8237,"duration_ms":141629,"concrete_test":"Re-run the Algorithm 2 allocation with a fraction of Byzantine actors: e.g., 20% of vehicles inflate RB by 50% and 20% of UAVs inflate AB/energy by 50% while true values are unchanged; measure the difference between on-chain QoV rankings and rankings computed from truthful data, and the resulting actual QoU/QoV and coverage/connectivity. Also test whether the contract accepts a proposal from a vehicle that names a non-max-QoU UAV; if it does, the two-sided selection's optimality claim is unenforced and the trust guarantee requires an off-chain verification or reputation-update mechanism.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim includes a blockchain-hosted two-sided relay selection that is 'transparent and trusted' (Section 3.2). This trust claim is load-bearing: the QoU/QoV gains in Section 4.2 and the stability claim in the abstract all assume that the data used for ranking is truthful. The contract does not verify any of it. registerUAV()/registerVehicle() accept location, bandwidth, energy, reputation, and payment at face value; reputation is initialized but there is no update, detection, or penalty mechanism for false reporting. Worse, Algorithm 1 is executed off-chain at the vehicle: submitVehSelection() receives a UAV address and a requested bandwidth, but the contract cannot check that the submitted UAV is actually the one maximizing QoU for that vehicle, nor can it validate the reported RB. allocateZone() then sorts purely on QoV/√RB computed from these unverified inputs. Thus adversarial vehicles can push themselves to the top of a UAV's selection list by inflating RB/payment, and adversarial UAVs can attract proposals by inflating AB/energy. The evaluation uses honest, uniformly sampled attributes, so the measured 10–13% QoU/QoV improvements and the 'stability' benefits disappear under even a modest fraction of false reporters; the framework provides execution transparency, not data integrity. This is the most load-bearing gap because the blockchain contribution is one of the paper's two advertised pillars and the selection mechanism's output is the input to the coordination task.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This manuscript proposes a three-component framework for UAV-assisted Internet of Vehicles: (i) a blockchain-hosted two-sided relay selection mechanism based on new Quality-of-UAV (QoU) and Quality-of-Vehicle (QoV) metrics; (ii) a decentralized Multi-Agent Deep Reinforcement Learning (MDRL) coordination model, trained with PPO under centralized learning and decentralized execution, with CNN policies and reduced local/global observations; and (iii) an IPFS/Solidity implementation for storing and distributing trained models. The evaluation consists of a static selection experiment against a nearest-neighbor matching variant, MDRL learning and coverage/connectivity experiments against centralized DRL and static placement, and a gas-cost analysis of the smart contract. The paper claims that the integrated framework improves relay stability, maximizes coverage and connectivity, and is scalable and cost-efficient.","tokens_in":18880,"tokens_out":11051,"duration_ms":114109,"significance":"If substantiated, this is a meaningful architectural contribution. The paper is among the first to couple blockchain-hosted two-sided relay selection with decentralized DRL-based UAV coordination, and the gas-cost analysis gives practical deployment information that is often missing in such designs. The observation-reduction design and the team reward are sensible, and the scalability comparison against centralized DRL is supported by parameter and FLOP counts. The strengths are the detailed system design, the explicit Markov-game formulation, and the fact that the evaluation is based on new simulations rather than on fitting parameters to pre-existing results. However, the current evidence does not validate the strongest advertised claims: relay stability is never measured, the blockchain trust model assumes honest reporting without any adversary treatment, and the selection and coordination components are evaluated separately. No code artifact or machine-checked proof is provided, so reproducibility rests on pseudocode and parameter tables.","major_comments":[{"comment":"The abstract and §5 claim that the selection mechanism improves the stability of the selected relays, but Section 4.2 contains no stability measurement. Figures 5-6 report only the number of vehicles per UAV, the percentage of selected UAVs, and the average QoU/QoV values. These are static one-shot outcomes, and QoU/QoV in Eqs. (1)-(2) are the very quantities the mechanism maximizes, so comparing them against a benchmark shows that the optimizer improves its own objective, not that the resulting relays are stable or yield better network performance. A longitudinal metric is required, e.g., selection churn, reassignment rate, or the duration of assignments under vehicle mobility, ideally followed by coverage/connectivity results computed on the assignments produced by the selection mechanism. Without such evidence, the abstract's stability claim is unsupported.","section":"Abstract, §4.2"},{"comment":"The blockchain-based selection is presented as transparent and trusted, but the trust claim is not established. The registration functions in Table 3 accept location, bandwidth, energy, reputation, and payment as self-reported values, and the reputation field is initialized but never updated or penalized. Algorithm 1 is executed off-chain by the vehicle, so the contract cannot verify that the submitted UAV is truly the one maximizing QoU; Algorithm 2 then ranks proposals by QoV/√RB computed from these unverified inputs. A vehicle can inflate RB or PayPerMbps, and a UAV can inflate AB or BL, to bias the ranking; the contract provides execution transparency but not data integrity. Since the evaluation in §4.2 uses honestly sampled uniform attributes, the reported QoU/QoV improvements and the subsequent coordination results assume an honest-reporting regime that is never stated or tested. Please add an explicit threat model with false-reporting rates, or a verification/reputation mechanism, or narrow the claim to transparent execution under honest reporting.","section":"§3.2, Tables 1-3, Algorithms 1-2"},{"comment":"Selection and coordination are never evaluated as an integrated pipeline. Section 4.2 evaluates the selection mechanism as a static allocation over the whole 50×50 km area with zones, while Section 4.3 trains MDRL per single zone with vehicles that are assumed to be assigned to each UAV based on the selection mechanism. No experiment executes Algorithms 1-2 and then uses their output to initialize the MDRL coordination task; nor is there a measurement of coverage or connectivity on the assignments produced by the blockchain component. The paper's central claim that the proposed selection and coordination mechanisms work together to improve stability and coverage is therefore not supported by the experiments. Please add an end-to-end evaluation, or explicitly present the results as component-level validations.","section":"§4.1, §4.2, §4.3"},{"comment":"The MDRL evaluation omits parameters that are essential to interpret the coverage and connectivity results. Coverage in Eq. (4) counts vehicles within the communication range of their allocated UAV, and connectivity requires a communication path between UAVs, but Table 5 does not list the UAV communication range, UAV speed, timestep duration, or the observation-window size n used in training. Figures 7-9 depend directly on these values, and the paper does not report sensitivity to them. Without the communication range and the other environment parameters, the learning curves and the final coverage/connectivity scores cannot be reproduced or compared with the benchmarks. Please specify these values and add a short sensitivity study.","section":"§4.1, Eq. (4)"},{"comment":"Section 4.4 validates only the gas cost of the smart contract; it does not test whether the contract logic correctly implements Algorithms 1-2. This matters because the pseudocode and the function signature are inconsistent: Algorithm 2, line 5, pushes the address of u into UAVS electionList u, but the surrounding text and the data structure indicate this should be the address of the selected vehicle v; and Table 3 lists QoV as an input parameter of submitVehS election(), while §3.2 says the function calculates the QoV. A correctness test on the Solidity implementation, such as unit tests checking allocation outcomes against the algorithms, would resolve these discrepancies and substantiate the feasibility claim. This is especially important if the contract is meant to be the trust anchor of the system.","section":"§4.4, Algorithm 2, Table 3"}],"minor_comments":[{"comment":"In line 5, the pushed address should be that of the vehicle v, not u; the pseudocode should match the text and the data structures.","section":"Algorithm 2"},{"comment":"Please clarify whether QoV is computed on-chain or supplied by the vehicle; the function signature and the prose currently disagree.","section":"Table 3, Algorithm 1"},{"comment":"The weights w1-w8 are free parameters set to 0.25 in Table 5, but no sensitivity analysis is reported; since the ranking depends on these weights, a brief sensitivity check would strengthen the selection results.","section":"§4.1, Eqs. (1)-(2)"},{"comment":"The observation-reduction size n is described as a tunable hyperparameter, but its value is not reported; please state the value used in the experiments.","section":"§3.3.1"},{"comment":"The figures show no error bars or confidence intervals despite the text reporting averages over 5 iterations for selection and 20 experiments for Fig. 9; please add variance information.","section":"Figs. 5-9"},{"comment":"Typographical and formatting issues remain, including the UA V spacing artifacts in the abstract and body, the malformed URL in footnote 2, and inconsistent reference formatting; a careful copy edit is needed.","section":"Throughout"},{"comment":"The limitation paragraph is transparent about energy and obstacle assumptions, but those caveats should be reflected in the abstract so that the reader is not left with unqualified coverage and connectivity claims.","section":"§5"}],"recommendation":"major_revision","confidential_remarks":"This is a systems/architecture paper with component-level simulations, and the main problem is the mismatch between the advertised claims and the evidence. The two weakest points are the abstract's stability claim, which has no corresponding metric, and the unvalidated honest-reporting assumption behind the blockchain trust claim. I do not see a fundamental correctness error that would force rejection; both issues are addressable by adding experiments or by narrowing the claims. The MDRL coordination design and the gas-cost analysis are the paper's strengths. If the revised version adds an adversarial-reporting simulation, a longitudinal stability metric, and an end-to-end test, or explicitly re-scopes the claims to component-level feasibility, I would support acceptance. I would not require a comparison with other blockchain mechanisms; a correctness test plus the existing cost analysis would be sufficient."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Two things worth knowing about arXiv:2502.15713. First, the integration itself is new: a blockchain-hosted two-sided relay selection (QoU/QoV) coupled with decentralized PPO-based UAV coordination hasn't appeared together before. Second, the paper is better than the abstract: the claims that are actually measured—QoU/QoV gains and coverage/connectivity scalability—survive contact with the evaluation, but the abstract's relay-stability claim is never measured, and the blockchain's \"trusted\" selection is only as good as unverified self-reported attributes.\n\nWhat it does well: the framework is coherent and the components are cleanly specified. The two-sided matching with capacity constraints on-chain is a reasonable extension of the authors' prior work (refs [10], [23]). The MDRL formulation is standard but carefully executed: CNN observations, team reward, CLDE training. The gas cost analysis is a nice touch—it shows the smart contract is deployable and cheap to run. The comparison against a centralized DRL agent shows a real scalability advantage in parameters and FLOPs.\n\nSoft spots, in order of severity. (1) The stability claim is load-bearing but unsupported. The abstract says the mechanism improves stability of selected relays, but stability is never defined or measured in the simulation section. This needs to be fixed before the summary is trustworthy. (2) The evaluation is not end-to-end. The selection mechanism is evaluated statically in MATLAB, and the MDRL coordination is evaluated separately with vehicles 'assumed to be assigned' based on the selection; the two are never coupled in one experiment, so the framework-level claim isn't demonstrated. (3) The trust model is thinner than advertised. The contract takes location, bandwidth, energy, reputation, and payment at face value, with no verification, update, or penalty mechanism for false reports. Algorithm 1 runs off-chain at the vehicle, so the contract cannot verify the submitted UAV is actually the argmax QoU. The QoU/QoV gains in Section 4.2 are computed under honest, uniformly sampled attributes; a modest fraction of adversarial reporters would bias allocations. That directly undermines the 'transparent and trusted' pillar. (4) The RL reward function is literally coverage + connectivity, so reporting those metrics as results is partly circular, though the learning curves and the comparison with centralized DRL still tell you something about scalability. Minor: no error bars (only 5 iterations for selection), no code release, and baselines are self-built modifications, so absolute numbers should be read cautiously.\n\nThe paper is a serious piece of systems research, not a breakthrough. It's for people working on UAV-assisted IoV, blockchain-based trust, or multi-agent coordination. I'd send it to referees, but with a clear instruction that the stability claim, the end-to-end coupling, and the trust model need substantial work. As a colleague, I'd read it if I were in the area, and I'd probably cite it as a reference framework.\n\nRecommendation: accept for peer review with major revision.","headline":"A solid framework integration for UAV-assisted IoV with blockchain-based two-sided relay selection and decentralized PPO coordination, but the headline stability claim is unmeasured, the evaluation is not end-to-end, and the blockchain's 'trusted' selection assumes honest self-reporting.","tokens_in":19421,"tokens_out":3211,"would_cite":true,"duration_ms":32025,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A blockchain-hosted smart contract and decentralized multi-agent reinforcement learning form a single framework that couples UAV relay selection with UAV coordination in Internet of Vehicles networks.","keywords":["Internet of Vehicles","UAV relay selection","Multi-Agent Deep Reinforcement Learning","Blockchain","Proximal Policy Optimization","Network coverage and connectivity"],"falsifier":"Run the selection mechanism with agents that inflate their reported bandwidth or reputation by 10 to 20 percent and check whether the allocation shifts toward the dishonest agents; if the matched set changes materially, the claimed transparent and trusted selection does not protect against false reporting.","tokens_in":18393,"feed_emoji":"📡","tokens_out":2809,"duration_ms":29956,"temperature":0.7,"pith_summary":"This paper argues that relay selection and relay coordination in UAV-assisted Internet of Vehicles should be coupled and executed transparently, rather than treated as separate centralized steps. To that end, it proposes a three-part framework: a blockchain-hosted smart contract that matches vehicles to UAV relays using two-sided quality metrics (QoU and QoV), a decentralized multi-agent deep reinforcement learning model using PPO that controls UAV mobility after selection, and IPFS storage for the trained models. The reported evaluations show the selection mechanism improves average QoU and QoV compared with a nearest-neighbor style baseline, and the MDRL coordination maintains high coverage and connectivity while scaling to more UAVs where a centralized DRL benchmark degrades.","feed_headline":"Blockchain and multi-agent RL keep UAV relays connected","feed_subtitle":"A smart contract runs two-sided relay matching; decentralized PPO moves the UAVs to hold coverage.","key_machinery":"The load-bearing objects are the two-sided quality metrics: QoU (available bandwidth, battery level, reputation, and inverse distance, weighted and normalized) computed by each vehicle for candidate UAVs, and QoV (requested bandwidth, payment per Mbps, reputation, and inverse distance) used by UAVs to rank proposers, with a smart contract allocation that sorts proposals by QoV over the square root of requested bandwidth. Coordination rides on a Markov Game formulation with a team reward $R_t = (\\text{coverage} - 1) + (\\text{connectivity} - 1)$, trained by Proximal Policy Optimization under centralized-learning/decentralized-execution, where each UAV's observations are four grid maps reduced into local windows and global downsampled maps and fed to a LeNet-style CNN actor-critic.","core_discovery":"The central claim is that a smart contract can run a two-sided relay selection in which each vehicle proposes the UAV with the highest Quality-of-UAV, and each UAV accepts vehicles ranked by QoV divided by the square root of requested bandwidth until its bandwidth is exhausted. Once selected, the UAVs are coordinated by a shared multi-agent PPO policy, trained with central learning and decentralized execution, using CNN-processed local and global grid observations and a team-based reward that penalizes loss of coverage or connectivity. The paper reports that this integrated design yields higher average QoU and QoV for the matched pairs, keeps coverage high as the number of vehicles grows, and reaches full connectivity within about 5% of an episode on average, while a centralized DRL baseline struggles as team size increases.","pith_inferences":["The trust and transparency claim depends on the reliability of data written to the blockchain; if vehicles or UAVs can submit inflated bandwidth, reputation, or payment values, the ranking and allocation could be biased, so adding verification oracles or slashing mechanisms would be a natural extension.","The coordination model assumes a 2D plane with no obstacles or signal interference; extending the observation maps to include no-fly zones, building footprints, or 3D altitude constraints would test whether the learned policy transfers to realistic urban environments.","Because trained models live on IPFS and are assigned by identifier through the smart contract, the same architecture could be reused for other mobile relay or crowdsensing settings where selection and post-selection coordination must be coupled and auditable."],"forward_implications":["If the framework works as described, operators get an auditable, on-chain record of which relay was selected and why, addressing traceability gaps in server-run or node-run selection.","Decentralized execution keeps per-agent model size at 1.692M trainable parameters regardless of team size, while a centralized agent grows from 1.692M to 9.31M parameters as UAVs increase from two to five, so the approach scales to larger teams.","The team reward pushes UAVs to reach full inter-UAV connectivity within about five timesteps of an episode while preserving coverage of assigned vehicles, even as vehicle counts increase.","Smart contract gas costs for registration, proposal submission, and zone allocation are low enough that the authors judge the framework feasible on a consortium blockchain such as Quorum."],"supporting_citations":[{"why":"Supplies the two-sided matching game model and dataset generation approach for UAV-assisted IoV relay selection that the proposed mechanism extends.","marker":"[10]"},{"why":"Provides the Proximal Policy Optimization algorithm used to train the multi-agent coordination policy.","marker":"[41]"},{"why":"Establishes the prior blockchain-enabled relay selection in VANETs that this paper adapts and extends to UAV-assisted IoV.","marker":"[12]"},{"why":"Serves as the static UAV placement benchmark using PSO and GA that the MDRL coordination is compared against.","marker":"[27]"},{"why":"Provides a centralized DRL benchmark for UAV trajectory planning whose scalability limits motivate the decentralized MDRL approach.","marker":"[30]"},{"why":"Provides another centralized DDPG-based DRL benchmark for UAV coverage in vehicular networks, used to highlight centralization drawbacks.","marker":"[20]"},{"why":"Identifies Quorum as the consortium blockchain platform on which the smart contract is deployed.","marker":"[36]"}],"fun_headline_variants":["Smart contract pairs UAVs and vehicles; PPO keeps coverage","Blockchain-secured relay matching plus multi-agent PPO for UAV IoV","Two-sided relay matching via smart contract, drone control via PPO","Coupling blockchain relay selection with decentralized multi-agent RL"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The selection's trustworthiness assumes vehicles and UAVs report their location, bandwidth, energy, reputation, and payment truthfully, because the smart contract reads these values from the chain without verification.","fun_headline_variants_meta":{"raw":{"variants":["Smart contract pairs UAVs and vehicles; PPO keeps coverage","Blockchain-secured relay matching plus multi-agent PPO for UAV IoV","Two-sided relay matching via smart contract, drone control via PPO","Coupling blockchain relay selection with decentralized multi-agent RL"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000719,"raw_usage":{"total_tokens":3258,"prompt_tokens":1007,"completion_tokens":2251,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":623,"completion_tokens_details":{"reasoning_tokens":2177}},"tokens_in":623,"tokens_out":2251,"duration_ms":15530,"temperature":1.0,"reasoning_tokens":2177,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T16:26:16.387049+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the selection mechanism with agents that inflate their reported bandwidth or reputation by 10 to 20 percent and check whether the allocation shifts toward the dishonest agents; if the matched set changes materially, the claimed transparent and trusted selection does not protect against false reporting.","supporting_citations":[{"cited_title":"Abualola, H","cited_arxiv_id":null,"evidence_quote":"Supplies the two-sided matching game model and dataset generation approach for UAV-assisted IoV relay selection that the proposed mechanism extends."},{"cited_title":"Kadadha, H","cited_arxiv_id":null,"evidence_quote":"Establishes the prior blockchain-enabled relay selection in VANETs that this paper adapts and extends to UAV-assisted IoV."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Serves as the static UAV placement benchmark using PSO and GA that the MDRL coordination is compared against."},{"cited_title":"Samir, D","cited_arxiv_id":null,"evidence_quote":"Provides a centralized DRL benchmark for UAV trajectory planning whose scalability limits motivate the decentralized MDRL approach."},{"cited_title":"Samir, D","cited_arxiv_id":null,"evidence_quote":"Provides another centralized DDPG-based DRL benchmark for UAV coverage in vehicular networks, used to highlight centralization drawbacks."},{"cited_title":"Accessed: 27-09-2023","cited_arxiv_id":null,"evidence_quote":"Identifies Quorum as the consortium blockchain platform on which the smart contract is deployed."}],"review_version":1}