{"id":"838fb7dc-54c9-417a-90f6-f43bab4d6df8","arxiv_id":"2505.03196","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"A blockchain-consensus layer over multiple LLMs is proposed to select power-allocation strategies, with a false-base-station defense simulation that claims near-optimal performance.","lead":"This paper proposes a blockchain-based layer that lets several large language models vote on the most reliable answer to a wireless-network optimization problem, then tests it on defending against fake base station attacks. The idea is that consensus among multiple LLMs is more trustworthy than any single model, though the supporting simulation is underspecified.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claim that Trustworthy MultiLLMN approaches the theoretical optimum is unfalsifiable as written: Section III-B defines the objective with P_FBSi but never gives its functional form, and Section IV-C never specifies how the 'optimal' baseline in Fig. 6 is computed.","rationale":"The reader's conditional verdict is appropriate. My stress-test converges on the same core weakness: the empirical comparison in Fig. 6 is unfalsifiable because neither the objective model P_FBSi nor the 'optimal' baseline is defined. I would phrase the issue slightly differently from the reader's weakest assumption: the more load-bearing gap is not primarily that two hand-picked few-shot examples give insufficient supervision, but that the evaluation framework itself has no stated P_FBSi model or optimal-computation procedure, so the plotted curves cannot be independently reproduced or checked. The 'model-free' claim in Section III-C deepens the concern, because the paper explicitly disclaims the need for a formal model while simultaneously reporting a quantitative distance to an optimum that only a formal model can define. This is not a matter of disagreement with the community consensus; it is an internal incompleteness in the validation. The architectural idea remains plausible, and the paper could become acceptable if the authors supply the missing model, the baseline algorithm, and the artifacts needed to rerun Fig. 6. Therefore I recommend no change to the reader's conditional verdict: the concern reinforces the existing 'revisions required before acceptance' posture rather than moving it to reject or accept.","tokens_in":8857,"tokens_out":3318,"duration_ms":33766,"concrete_test":"Ask the authors to release the exact P_FBSi function used to score allocations, for example a threshold or sigmoid on the SINR expression from reference [14], together with the optimization routine that produced the 'optimal' curve in Fig. 6. Independently implement that model with the Section IV-A parameters (30 LBSs, 10 FBSs, 2 kW total power, 80 W per FBS, path-loss exponent 2.5, noise power 4e-14 W, 20 MHz bandwidth) and compute the true optimal allocation, then compare the published MultiLLMN curve against this recomputed optimum. If the baseline moves or cannot be reproduced, the asymptotic optimality claim fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that blockchain voting among ten LLMs yields power allocations that asymptotically approach the theoretical optimum. That comparison depends on two things the paper never supplies: (1) a concrete model for P_FBSi, the probability that an FBS successfully binds to a UE, and (2) a definition or algorithm for the 'optimal' allocation plotted in Fig. 6. Section III-B states the objective as max sum(1-P_FBSi)/n but gives no functional form for P_FBSi; the surrounding text only says the success of an FBS attack depends on SINR, citing reference [14]. Section IV-C says the proposed scheme is compared with 'optimal' power allocation, but it does not state how that optimum is computed, whether by exhaustive search, convex relaxation, or a grid over the 30-LBS allocation space. Without P_FBSi, the average defense probability in Fig. 6 cannot be reproduced, and without an explicit optimal-baseline computation, the claimed convergence to the optimum cannot be checked. The paper's own 'model-free' positioning in Section III-C makes this gap intrinsic rather than a minor omission: the framework is presented as not requiring a formal model, yet the evaluation quantitatively compares against an optimum that is only definable through such a model. Additionally, 'asymptotically approaches' is not tied to a defined x-axis or convergence criterion, and no error bars or random-seed information are reported for stochastic LLM outputs. The architecture may be reasonable, but the empirical validation of the headline result is not verifiable as written.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes Trustworthy MultiLLMN, a blockchain-enabled architecture in which multiple LLMs act as blockchain nodes, generate candidate power-allocation solutions, and reach consensus through voting. The authors apply the framework to False Base Station (FBS) defense in a simulated 5G/6G scenario with 30 LBSs and 10 FBSs, compare four consensus mechanisms in terms of response latency, and evaluate attack-defense performance against single-LLM, MultiLLMN, optimal, and random baselines. The main claim is that Trustworthy MultiLLMN provides near-optimal power allocations that asymptotically approach the theoretical optimum while remaining robust to malicious LLMs.","tokens_in":9118,"tokens_out":4936,"duration_ms":43362,"significance":"If the empirical claims were fully supported, the work would make a useful contribution by demonstrating that a decentralized multi-LLM consensus framework can produce network-optimization decisions that are resilient to malicious LLMs. The consensus-latency comparison in Fig. 5 is a concrete, reproducible element, and the paper is among the first to couple blockchain consensus with multi-LLM collaboration for wireless security. However, the central performance claim in Fig. 6 is not presently falsifiable because the underlying FBS-defense model and the optimal baseline are not specified. The paper provides no code, no error bars, and no reproducible artifacts, so the headline result remains a plausible architecture claim rather than a validated empirical finding.","major_comments":[{"comment":"The optimization objective max sum_i (1 - P_FBSi)/n is stated without a functional form for P_FBSi; the text only says that FBS success depends on SINR and cites reference [14]. As a result, the average resistance probability reported in Fig. 6 cannot be computed, reproduced, or interpreted by a reader. Please provide the explicit expression for P_FBSi, or a precise pointer to the specific equation in [14], and state all parameters used in its evaluation.","section":"Section III-B"},{"comment":"The baseline labeled 'optimal' in Fig. 6 is never defined. The paper does not state whether the optimum is obtained by exhaustive search over the 30-LBS power-allocation space, by convex relaxation, by grid search, or by any other algorithm, nor does it define the x-axis or the sense in which the proposed scheme 'asymptotically approaches' the optimum. Without this definition, the central claim of near-optimality is unfalsifiable. Please specify the optimal-allocation computation, the grid or search procedure, and the convergence criterion used to produce Fig. 6.","section":"Section IV-C"},{"comment":"The two few-shot prompt examples are hand-selected anchors that directly encode the power-to-defense-probability mapping (30/40/40/50 W maps to 85% and 20/30/40/50 W maps to 83%), and the same average defense probability is used as the evaluation metric. If the 'optimal' baseline is computed from the same underlying model that generated these anchors, the evaluation risks being circular: the LLM is being scored against a target that the prompt examples already reveal. As a concrete corrective test, please specify the model, compute the optimal baseline explicitly, and evaluate on held-out prompt examples that were not used as anchors; alternatively, state this circularity as an explicit limitation.","section":"Section III-C.2 and Section IV-C"},{"comment":"No details are given about the stochastic behavior of the LLM outputs: the number of simulation runs per configuration, the random seeds, the temperature settings, or the exact prompt templates beyond the two examples. Without this information, the curves in Fig. 6 cannot be regenerated, and the claimed ordering of Trustworthy MultiLLMN over single LLM and MultiLLMN is not statistically grounded. Please report error bars or multiple independent runs and specify all LLM-inference settings, including the implementation of the two malicious LLMs.","section":"Section IV-A and Section IV-C"}],"minor_comments":[{"comment":"The power-allocation vector is written as 'p1, p3, p3,..., pi−1, pi', which should presumably be 'p1, p2, p3, ..., p_{n-1}, p_n'; the current form contains a typo and an inconsistent index.","section":"Section III-B"},{"comment":"The notation uses 'i' both as an index and as the total number of LBSs; please use n for the total count and i for the index throughout the model description.","section":"Section III-B"},{"comment":"The prompt example 'the power of i LBSs is 30W, 40W, 40W, 50W, and others' is ambiguous; it should state how many LBSs receive the listed powers and how the remaining LBSs are allocated, especially since the simulation uses 30 LBSs.","section":"Section III-C.2"},{"comment":"The LLM communication parameters are given as 'bandwidth, channel capacity, and transmission rates of 80 kHz, 15 kps, and 10 kps'; the units for channel capacity and transmission rate should be stated consistently, and 80 kHz is a bandwidth rather than a transmission rate.","section":"Section IV-A"},{"comment":"Figure 6 is not described with axis labels or a legend in the text; please specify the x-axis quantity (for example, number of LBSs, total power, or consensus round) so that the reader can interpret the claimed convergence.","section":"Section IV-C"},{"comment":"The text says 'we have described in detail in Section III-B' when referring to the Trustworthy MultiLLMN workflow, but the workflow is described in Section II-C; the cross-reference appears to be incorrect.","section":"Section III-C.3"}],"recommendation":"major_revision","confidential_remarks":"The paper's topic fits the venue and the proposed architecture is reasonable, but the central simulation claim needs substantial revision before publication. The missing P_FBSi model and the undefined optimal baseline are not merely presentation issues; they are necessary for the paper's main conclusion. I recommend major revision rather than rejection because the authors can likely supply these details, but if the underlying model and optimal baseline cannot be provided in a reproducible form, the key claim of near-optimal performance should not be accepted."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The core idea here is real and moderately new: use blockchain consensus to pick the best response from several LLMs instead of trusting any one model or a central coordinator. The FBS power-allocation case study is a sensible testbed, and the paper is clearly written, with a reasonable review of related work on both multi-LLM collaboration and blockchain for AI-generated content. I don't see this exact combination elsewhere, so the novelty claim is fair, though modest—it is an assembly of known components rather than a conceptual leap.\n\nThat said, the stress-test is right: the main empirical result is unfalsifiable as written. Section III-B defines the objective as max Σ(1−P_FBSi)/n but never gives the functional form of P_FBSi. The text only says it depends on SINR, citing reference [14]. Section IV-C then compares against an \"optimal\" power allocation without saying how that optimum was computed—exhaustive search, convex relaxation, or a grid. There are no error bars, no random-seed information, and no code. So Figure 6 cannot be reproduced, and the claim that the scheme \"asymptotically approaches the theoretical optimum\" is just not checkable.\n\nThe tension is even sharper because the paper stresses that its approach needs no formal model, yet the evaluation quietly depends on one to define the optimum. That is an internal contradiction, not just a missing detail. The hand-picked few-shot prompts (30/40/40/50 W → 85%) are also doing a lot of work; they are essentially anchors that encode a power-to-defense-probability mapping. Asking an LLM to interpolate from two examples is not a demonstration of near-optimality.\n\nStill, I would not reject this outright. The architecture is plausible, and the problems in Section IV-C are fixable. If the authors define P_FBSi (even by borrowing the model from [14] and stating it clearly), spell out the optimal-baseline algorithm, and report variance or seeds, the paper could be solid. The response-efficiency comparison in Figure 5 is more self-contained and gives some value on its own.\n\nFor a reader in AI-native network optimization or blockchain for IoT, this is worth reading with caution. It is not a breakthrough, and the current version does not support its headline claim. But a serious referee could guide the authors toward the missing pieces. I would send it to peer review, with a strong request for revision. The reader's CONDITIONAL verdict is my verdict too: the idea survives, but the evidence as presented does not.","headline":"The paper has a genuinely plausible idea—blockchain voting to make multi-LLM collaboration trustworthy—but its central simulation claim is unverifiable as written because the FBS model and the 'optimal' baseline are never defined; worth one serious revision.","tokens_in":9725,"tokens_out":1911,"would_cite":false,"duration_ms":20024,"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":"This paper argues that a blockchain-run committee of ten large language models can pick base-station power allocations that defend against false base stations almost as well as the theoretical optimum, needing only a few example prompts…","keywords":["large language models","multi-LLM collaboration","blockchain consensus","trustworthy AI","false base station attacks","power allocation","6G security","few-shot prompting"],"falsifier":"Remove the two example power-probability pairs from the prompt and re-run the 30-LBS, 10-FBS, 2 kW simulation with an explicit SINR-based formula for $P_{\\mathrm{FBS}_i}$ and a numerical optimizer as the optimum; if the defense probability no longer approaches that optimum, the near-optimality is due to the handpicked prompt examples rather than to blockchain voting.","tokens_in":8633,"feed_emoji":"📡","tokens_out":14262,"duration_ms":126133,"temperature":0.7,"pith_summary":"The paper proposes that connecting several LLMs into a blockchain run by the models themselves can make LLM-based wireless network optimization trustworthy, and it tests this idea on false base station (FBS) attacks in 5G and 6G systems. Each LLM acts as a full blockchain node and proposes a transmit-power allocation for legitimate base stations (LBSs); voting consensus selects the response the majority judges best, and the winning allocation is stored with a hash and timestamp. In simulations with ten LLMs, two of them set to behave maliciously, the framework's average defense probability asymptotically approaches the theoretical optimum and clearly beats a single LLM, an unsecured multi-LLM group, and random allocation. The appeal for a reader is that the approach promises near-optimal security decisions without building a scenario-specific optimization model or training a deep network from scratch, only by prompting.","feed_headline":"Blockchain vote of 10 AI models nears optimal wireless defense","feed_subtitle":"Ten LLMs vote via blockchain to allocate power against fake base stations, using only a few prompt examples.","key_machinery":"The load-bearing mechanism is the blockchain consensus layer, specifically voting-based consensus, with PBFT (practical Byzantine fault tolerance) used in the performance evaluation, which turns each LLM into a full node of a peer-to-peer blockchain. Each node first generates an answer to the network operator's question, the nodes broadcast their answers, the consensus algorithm selects the best response, and the winner is recorded on-chain with its hash and timestamp. This mechanism replaces a central coordinator, avoiding a single point of failure, and lets honest LLMs outvote malicious ones, which is what the paper credits for the defense-probability gain. The second piece of machinery is the few-shot prompt, with two worked examples of power-probability pairs, which gives the LLMs the supervision they need to map total power and LBS count to an allocation.","core_discovery":"For the FBS use case, the paper's central empirical claim is that blockchain-driven voting among ten LLMs yields transmit-power allocations whose average defense probability converges toward the theoretical optimum in a scenario with 30 LBSs, 10 FBSs, and 2 kW total power, while single-LLM, unsecured multi-LLM, and random allocations fall short. The claimed reasons are that majority voting over diverse LLM outputs filters deceptive suggestions from malicious nodes, on-chain storage with a hash and timestamp makes the decision auditable, and the few-shot examples in the prompt give LLMs enough grounding to propose sensible power splits. The paper presents this as evidence that Trustworthy MultiLLMN can solve network optimization problems without a formal model of the channel or the attack and without retraining, using only natural-language prompts and blockchain consensus.","pith_inferences":["Beyond the paper, the few-shot prompt sensitivity could be tested by replacing the two example power-probability pairs with different values; stable outputs would indicate that the consensus mechanism, rather than the handpicked examples, drives the near-optimal allocations.","Beyond the paper, giving each LLM a voting weight derived from its historical accuracy or the trustworthiness of its host device could further close the gap to the optimum, since the paper currently weights all ten nodes equally.","Beyond the paper, the same recipe could be benchmarked against mixture-of-experts or secure multi-party computation alternatives to separate the contribution of blockchain from the contribution of combining several LLMs.","Beyond the paper, the portability of the framework could be tested by reusing the same prompt structure for other allocation tasks, such as spectrum sharing or routing, where only the scenario description changes."],"forward_implications":["Network operators could obtain FBS-defense power allocations by describing the scenario in natural language and letting the LLM committee vote, without reformulating an optimization model or retraining when the scenario changes.","Because consensus rather than a central controller chooses the response, the system can keep operating if some LLM nodes are compromised, as long as the honest nodes form the majority.","Each accepted allocation is stored on-chain with a hash and timestamp, so the decision history is auditable and tamper-evident.","The latency comparison identifies a reliability-efficiency tradeoff among consensus protocols, with ABC-PBFT giving the fastest response by narrowing consensus participation, so the protocol can be chosen to meet a specific latency budget.","If the case-study result transfers, the same prompt-and-vote recipe can be applied to other wireless optimization problems, such as spectrum or routing decisions, by changing the prompt content."],"supporting_citations":[{"why":"It supplies the SINR-based model of false base station attacks that makes LBS transmit power the decision variable and motivates the average defense-probability objective.","marker":"[14]"},{"why":"It defines the four blockchain consensus mechanisms whose latency and voting behavior drive the Trustworthy MultiLLMN evaluation.","marker":"[15]"},{"why":"It establishes the multi-LLM collaboration premise by showing that an ensemble of LLMs outperforms a single LLM through cross-model validation.","marker":"[4]"},{"why":"It supports the claim that LLMs can act as prompt-based optimizers without scenario-specific training.","marker":"[12]"},{"why":"It provides the malicious-LLM threat model that motivates adding a blockchain trust layer to filter deceptive responses.","marker":"[7]"}],"fun_headline_variants":["10 LLMs vote via blockchain to near-optimal wireless defense","Blockchain-voted LLMs beat single models in FBS attack defense","Multi-LLM blockchain vote approaches optimal power allocation","Voting LLMs on-chain bolster 6G defense against fake base stations","Trustworthy multi-LLM network: blockchain voting for near-optimal defense"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The argument depends on two short example power allocations in the prompt being enough for ten large language models to propose near-optimal power splits in the test scenario, and on a well-defined theoretical optimum existing for comparison.","fun_headline_variants_meta":{"raw":{"variants":["10 LLMs vote via blockchain to near-optimal wireless defense","Blockchain-voted LLMs beat single models in FBS attack defense","Multi-LLM blockchain vote approaches optimal power allocation","Voting LLMs on-chain bolster 6G defense against fake base stations","Trustworthy multi-LLM network: blockchain voting for near-optimal defense"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000254,"raw_usage":{"total_tokens":1568,"prompt_tokens":946,"completion_tokens":622,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":562,"completion_tokens_details":{"reasoning_tokens":530}},"tokens_in":562,"tokens_out":622,"duration_ms":6497,"temperature":1.0,"reasoning_tokens":530,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T23:56:52.361943+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Remove the two example power-probability pairs from the prompt and re-run the 30-LBS, 10-FBS, 2 kW simulation with an explicit SINR-based formula for $P_{\\mathrm{FBS}_i}$ and a numerical optimizer as the optimum; if the defense probability no longer approaches that optimum, the near-optimality is due to the handpicked prompt examples rather than to blockchain voting.","supporting_citations":[{"cited_title":"Protecting system information from false base station attacks: A blockchain-based approach,","cited_arxiv_id":null,"evidence_quote":"It supplies the SINR-based model of false base station attacks that makes LBS transmit power the decision variable and motivates the average defense-probability objective."},{"cited_title":"Symbiotic blockchain consensus: Cognitive backscatter communications-enabled wireless blockchain consensus,","cited_arxiv_id":null,"evidence_quote":"It defines the four blockchain consensus mechanisms whose latency and voting behavior drive the Trustworthy MultiLLMN evaluation."},{"cited_title":"Large language models as evolutionary optimizers,","cited_arxiv_id":null,"evidence_quote":"It supports the claim that LLMs can act as prompt-based optimizers without scenario-specific training."},{"cited_title":"WormGPT: A large language model chatbot for criminals,","cited_arxiv_id":null,"evidence_quote":"It provides the malicious-LLM threat model that motivates adding a blockchain trust layer to filter deceptive responses."}],"review_version":1}