{"id":"7acf6c13-2cec-4bd4-8972-fe2bf344facc","arxiv_id":"2501.16369","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"The paper designs a consortium-blockchain platform with smart contracts and greedy worker selection for crowdsourced deep reinforcement learning training and model sharing.","lead":"This paper proposes a blockchain-based service where users can crowdsource the training and sharing of deep reinforcement learning models to expert workers. It offers a new way to make DRL more accessible to people who lack the expertise or computing power.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Efficacy claim unsupported: no experiment tests the full DRLaaS loop (registration, smart-contract allocation, worker training, IPFS model return); component-level results on CPU/GPU/similarity and gas costs do not demonstrate end-to-end service quality.","rationale":"Good faith: the paper contributes a clear architectural description, two QoS metrics with sensible intuitions, and component-level evidence that CPU/GPU resources and environment similarity affect DRL training. The gas-cost analysis supports feasibility of the smart contracts. However, the central claim is about the efficacy of the whole framework, and no experiment exercises the whole framework. The component experiments are necessary but not sufficient: even if each metric captures a relevant factor, the recruitment optimization and blockchain workflow could fail to deliver the promised service. The self-reporting weakness identified by the Reader is real and serious—the framework has no verification of worker-declared CPU/RAM/GPU or model environment details (Section 4.4), and the paper's future-work section explicitly acknowledges missing quality control. Yet that concern is secondary to the evidentiary gap: an end-to-end test with truthful workers is the minimum needed to support 'proving its efficacy.' The reader's weakest_assumption is about truthful reporting; I agree with that as one concern but consider the lack of integrated validation more load-bearing, so agreement is partial. The conditionality of the reader's verdict is appropriate; my concern reinforces the need for an end-to-end demonstration rather than changing the verdict.","tokens_in":19728,"tokens_out":5967,"duration_ms":62492,"concrete_test":"Deploy the three smart contracts on a test consortium blockchain (e.g., Quorum or Ganache) and run the full loop: (1) register 20+ simulated workers with varied but truthful attributes via UMC; (2) submit a DRL training task for the maze-cleaning environment through TMC; (3) execute allocateTask() and observe the selected workers; (4) have each selected worker actually train the PPO model on hardware matching their declared CPU/GPU for a fixed wall-clock budget, upload the result to IPFS, and call submitOutcome(); (5) have the requester evaluate the episode-length of the returned models and compare against a baseline trained without the framework.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 5 never validates the proposed system as an integrated service. The experiments isolate individual recruitment metrics: Figs. 6-7 show CPU cores and GPU availability affect training speed/convergence in three DRL environments; Fig. 8 shows environment similarity helps demonstration-cloning; Figs. 9-10 compare the greedy allocation to heuristics on a synthetic 600-worker dataset. In the sole experiment that connects recruitment to DRL outcome (Fig. 10b), 'workers' are simulated by running training on hardware with the declared attributes of selected workers; no actual worker decides to accept a task, trains a model, or uploads it. The smart contracts (Section 4.4) are evaluated only by gas-cost estimates in Table 5; they are never deployed or executed on a blockchain, and the allocateTask()/allocateModel() functions are not run against a live ledger. Therefore, the central claim that the framework provides effective DRL training and model sharing services—and the abstract's assertion that the framework 'is tested on several DRL applications, proving its efficacy'—does not follow from the presented evidence. The user-requester loop of task submission, greedy worker selection, actual distributed training, IPFS-based model delivery, and payment/rating is entirely unexercised. Even if workers report attributes truthfully, the framework could still fail in practice due to unmodeled interaction between the QoS formula and real training dynamics; the paper provides no evidence that the selected workers' QoS ordering corresponds to delivered model quality.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes a consortium-blockchain-based crowdsourced Deep Reinforcement Learning as a Service (DRLaaS) framework that supports two task types: DRL training and model sharing. It defines QoS metrics for worker recruitment (Eqs. 5-8), uses a greedy optimization for worker and model allocation, describes three smart contracts (UMC, TMC, MMC) with IPFS-based model storage, and reports experiments on CPU/GPU effects, model similarity in demonstration cloning, recruitment optimization on a synthetic 600-worker dataset, and smart-contract gas costs. The central claim, stated in the abstract and conclusion, is that the framework provides effective DRL training and model sharing services and that its efficacy is proven by the experiments.","tokens_in":19994,"tokens_out":5352,"duration_ms":56991,"significance":"The paper addresses a real gap: making DRL accessible through crowdsourced expertise, computational resources, and pre-trained models. Its main contributions are a concrete system architecture for DRLaaS, DRL-specific worker recruitment metrics, and a smart-contract design for task/model allocation. The component-level experiments on three multi-agent DRL environments (target localization, maze cleaning, fleet coordination) usefully demonstrate that CPU parallelism and GPU availability affect DRL training throughput and that similar pre-trained models can help demonstration cloning. The gas-cost analysis gives a rough feasibility check for the smart contracts. However, the significance is currently limited by the absence of an integrated evaluation of the proposed service loop and by unverified assumptions about truthful worker reporting and the functional forms of the QoS metrics.","major_comments":[{"comment":"The evaluation does not exercise the proposed DRLaaS framework as an integrated service. The full loop of requester task submission, smart-contract-based allocation, actual worker training or model sharing, IPFS-based model return, payment, and rating is never run; the smart contracts appear only as gas-cost estimates in Table 5 and are not deployed or executed on a ledger. Consequently, the abstract's statement that the framework 'is tested on several DRL applications, proving its efficacy' is not supported by the presented evidence, which validates components in isolation rather than the system-level service claim.","section":"Section 5"},{"comment":"The validation of the computational-capability component is partly tautological. The QoS in Eq. (6) includes CCWj from Eq. (5), which is built on the number of CPU cores, and the task constraints in Section 4.2.1 include GPU availability; Figs. 6 and 7 then show that more CPU cores and the presence of a GPU speed up DRL training. This confirms that these attributes are relevant, but it does not validate the specific functional form of Eq. (5) or the multiplicative combination in Eq. (6). A simple hardware filter would likely produce the same training-speed differences, so the experiments do not show that the QoS metric selects better workers beyond what such a filter would achieve.","section":"Section 4.2.1 and Section 5.2.1"},{"comment":"The framework's correctness depends on workers truthfully reporting their computational capabilities (CPU cores, RAM, GPU series) and model environment details, but no verification mechanism, benchmark, or proof-of-computation is described. If workers misreport these attributes, the greedy allocation in Section 4.3 selects the wrong workers and the QoS values become meaningless. The conclusion mentions future quality-control mechanisms, but the current design does not mitigate this dependency, which is load-bearing for the claim that the service is effective.","section":"Sections 4.4-4.5, Tables 2-4"},{"comment":"The model similarity metric is not actually validated as a ranking function. Figure 8 compares a few hand-picked expert models by their environment labels (e.g., 2A2W vs 3A3W), showing qualitatively that closer environments help; however, the paper never computes S(m,Ti) for these models, never varies the weights wn in Eq. (7), and never tests whether the top-ranked models under Eq. (7) yield better training outcomes. The model-sharing allocation process is therefore unsubstantiated.","section":"Section 5.2.2 and Eq. (7)"},{"comment":"The comparison against GA, PSO, and ACO on a synthetic 600-worker dataset provides weak evidence for the recruitment method. When the objective is the additive sum of worker QoS values, selecting a group of size N is achieved exactly by greedy top-k selection, so it is unsurprising that greedy outperforms general-purpose metaheuristics on that objective. Moreover, in Fig. 10b the 'workers' are simulated by running training on hardware with the declared attributes of selected workers; no actual worker accepts a task, trains a model, or uploads it, so the experiment does not demonstrate distributed crowdsourced training.","section":"Section 5.2.3, Figs. 9-10"}],"minor_comments":[{"comment":"The notation for worker attributes is inconsistent: the text uses subscripts such as DomTi in Rep Wj Tr-DomTi while Table 1 defines DomTi as the task domain, and the worker tuple mixes DomWj and DomTj; please unify the notation.","section":"Section 4.1, Table 1"},{"comment":"The commitment rate CM and completion rate CP are undefined when the total assigned tasks or accepted tasks are zero; initial values for new workers should be specified explicitly.","section":"Section 4.2.1, Eqs. (2)-(3)"},{"comment":"The caption contains a typo: the second subfigure is labeled '(a) varying the use of GPU' but should be '(b)'.","section":"Figure 7 caption"},{"comment":"The environment attributes Fn in Eq. (7) appear to be raw counts (e.g., number of agents, number of walls), so the weighted sum of absolute differences is scale-dependent; the paper should discuss normalization before summing attributes of different units or magnitudes.","section":"Section 4.2.2, Eq. (7)"},{"comment":"The table entry 'updateInfo)' has a typo and should read 'updateInfo()'; also, the discussion would benefit from stating whether the gas costs are estimates obtained from a simulator or from a deployed contract.","section":"Section 5.2.4, Table 5"}],"recommendation":"major_revision","confidential_remarks":"This is a systems/design paper with a plausible architecture and useful component-level experiments, but the current claims exceed the evidence: the service loop is not evaluated end to end, and the recruitment and similarity metrics rely on unverified assumptions. I would encourage the editor to require either a small integrated proof-of-concept (even a simulated blockchain with scripted workers) or a careful reframing of the claims to component validation, together with a discussion of the misreporting threat. The novelty relative to prior blockchain-DRL and MLaaS-crowdsourcing work is adequately positioned, though the related work section could be tightened."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nShort version: the paper's actual novelty is a system design for crowdsourcing DRL training and model sharing on a consortium blockchain, with QoS-based greedy worker recruitment. That is a real gap in the literature; existing crowdsourcing-for-ML work stops at data labeling and annotation. The paper makes a sensible case that DRL's compute and expertise needs make centralized MLaaS awkward, and the two task types are well specified. The component experiments are also honest: CPU cores and GPU availability do speed up training in three multi-agent DRL environments, and model similarity gives better demonstration cloning. I believe those results.\n\nThe problem is the packaging. The abstract says the framework 'is tested on several DRL applications, proving its efficacy,' but Section 5 never runs the actual service. The smart contracts are costed in gas estimates, not executed on a ledger. The 'workers' in Fig. 10b are the machine running with selected workers' declared attributes; no worker accepts a task, trains, or uploads a model. The recruitment comparison in Fig. 9 is on a synthetic dataset with uniformly drawn attributes, which is fine for sanity-checking the greedy algorithm but says nothing about real worker behavior. And the QoS formulas depend on free parameters w1 and wn that are never specified or swept, so the reader cannot tell how sensitive the allocations are.\n\nThere are two other soft spots, roughly equal in severity. The framework trusts workers to self-report CPU cores, RAM, GPU series, and environment details, and there is no verification or proof-of-computation. Misreporting breaks the greedy selection. The paper mentions quality control only as future work. Second, the training and similarity metrics—while reasonable—are validated in isolation, and the link between QoS ordering and delivered model quality is only demonstrated in one maze-cleaning experiment with one run, no error bars.\n\nNone of this kills the idea. The framework is plausible and the building blocks are standard. But the validation is not yet at the level of the claims. A serious revision needs reproducible artifacts, specified parameters, multi-seed results, and at least a simulated end-to-end workflow with smart-contract execution.\n\nMy recommendation: send it to review. The novelty is real and the flaws are fixable. I'd flag the efficacy claim as needing rewrite.","headline":"New service model worth taking seriously, but the experiments are component demos, not an end-to-end proof of efficacy.","tokens_in":20544,"tokens_out":3131,"would_cite":true,"duration_ms":30302,"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 proposes a blockchain-based crowdsourcing framework that treats deep reinforcement learning as a service, letting requesters hire expert workers for DRL training and for sharing pre-trained models.","keywords":["deep reinforcement learning","crowdsourcing","blockchain","machine learning as a service","smart contracts","worker recruitment","quality of service","model sharing"],"falsifier":"Let workers register with inflated hardware and model-environment claims, run the greedy allocation, and audit the actual resources and model metadata; if misreporting workers are selected and then fail to train or share usable models at the promised speed, the central claim that QoS metrics pick effective workers would be falsified. A cleaner test is to compare training outcomes and wall time for identical tasks allocated with truthful versus inflated profiles, holding everything else fixed.","tokens_in":19529,"feed_emoji":"🤖","tokens_out":4813,"duration_ms":51517,"temperature":0.7,"pith_summary":"The paper is trying to establish that deep reinforcement learning can be offered as a crowdsourced service rather than only through centralized MLaaS platforms. It proposes a consortium-blockchain framework where requesters submit DRL training tasks or model-sharing requests, smart contracts recruit workers using quality-of-service scores, and trained models are stored on IPFS. The authors argue that existing MLaaS is ill-suited to DRL because of its computational cost, environment variability, and need for expert design, and they report experiments on three multi-agent DRL applications showing that their recruitment metrics select workers whose resources speed up training and whose shared models improve learning. If the framework works as described, it would broaden access to DRL expertise and compute.","feed_headline":"Blockchain lets anyone crowdsource DRL training and models","feed_subtitle":"A smart-contract framework recruits expert workers for reinforcement-learning tasks and shares pre-trained models.","key_machinery":"The load-bearing machinery is the QoS-driven greedy knapsack allocation executed by smart contracts. For DRL training, each worker's QoS is $\\text{Exp} \\times \\text{Rep} \\times R \\times CC$, where $CC = \\frac{2}{\\pi} \\tan^{-1}(w_1 N_{\\text{CPU}})$ captures the saturating benefit of parallel CPU cores; the requester's constraints filter workers by reputation, rating, domain, CPU, RAM, and accepted GPU series. For model sharing, QoS is $\\frac{\\text{Exp} \\times \\text{Rep} \\times R}{1 + S}$, where $S$ is a weighted sum of absolute differences between environment attributes of the shared model and the task. Three smart contracts, named Users Manager, Tasks Manager, and Models Manager, store worker, task, and model records on-chain and use IPFS content identifiers for model files; allocation functions sort candidates greedily at $O(N \\log N)$, a complexity chosen for blockchain deployability.","core_discovery":"On its own terms, the paper's central claim is that a consortium blockchain can autonomously manage the full lifecycle of crowdsourced DRL: user registration, task submission, QoS-based worker selection, model delivery via IPFS, feedback, and payment. The training-task QoS is the product of normalized expertise, reputation, rating, and a computational-capability score that saturates with CPU count and checks GPU and RAM thresholds; the model-sharing QoS divides the same human-factor product by one plus a weighted environment-similarity distance. The evaluation reports that more CPU cores mainly reduce wall-clock training time, GPU use increases training steps by up to 19 times, and expert models from closer environments improve convergence, while greedy recruitment beats genetic, particle-swarm, and ant-colony benchmarks on group QoS and is far faster, and smart-contract gas costs are modest.","pith_inferences":["An unstated corollary is that the framework's integrity depends on a reputation and verification layer that the paper does not design; without one, workers can inflate their reported hardware or model attributes to win tasks.","The environment-similarity metric assumes that a fixed, weighted set of environment attributes can represent any DRL domain, which may be difficult to generalize beyond the three tested applications.","The framework could be extended to include on-chain quality verification of submitted models, such as benchmark reward checks, but the paper leaves that to future work.","A testable extension would be to simulate strategic workers who misreport capabilities and measure the resulting degradation in training outcomes, which would reveal how much of the claimed efficacy relies on honest reporting."],"forward_implications":["A requester with no DRL expertise can submit a problem description and receive a trained model from a recruited expert worker, with payments and records handled automatically by smart contracts.","Workers with more CPU cores and GPUs receive higher QoS scores, and the experiments show these resources mainly compress wall-clock training time rather than change convergence behavior.","Model sharing with environment-similar pre-trained models speeds learning; the closer the shared model's environment attributes are to the requester's, the faster the convergence.","Greedy recruitment yields higher group-average QoS and is orders of magnitude faster than genetic, particle-swarm, and ant-colony benchmarks, making on-chain allocation practical.","Smart-contract gas costs are low enough to deploy on a consortium blockchain, which avoids single-point-of-failure and provides traceable, autonomous task execution."],"supporting_citations":[{"why":"Provides the architectural baseline for MLaaS that the paper argues is infeasible for DRL.","marker":"[8]"},{"why":"Defines the target localization multi-agent DRL environment used in the evaluation.","marker":"[17]"},{"why":"Supplies the demonstration-based learning motivation for why shared pre-trained models help DRL training.","marker":"[18]"},{"why":"Defines the fleet coordination environment used as one of the three DRL test applications.","marker":"[20]"},{"why":"Defines the multi-agent maze cleaning environment used in the training and recruitment experiments.","marker":"[21]"},{"why":"Supplies the reputation-based recruitment benchmark that the proposed QoS metric is compared against.","marker":"[28]"},{"why":"Provides the demonstration cloning method and expert-model assistance used to test the model sharing service.","marker":"[34]"},{"why":"Offers a blockchain-based crowdsourcing implementation whose smart-contract gas cost is used as a benchmark.","marker":"[37]"},{"why":"Defines IPFS, the content-addressable storage system used for tamper-proof distribution of trained models.","marker":"[41]"}],"fun_headline_variants":["Blockchain crowdsources DRL training and models","Smart contracts power a DRL crowdsourcing marketplace","Crowdsourced DRL as a service on a blockchain","Trade DRL tasks and models via blockchain smart contracts"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The framework assumes workers truthfully report their CPU cores, RAM, GPU series, and the environment attributes of their shared models, and that these self-declared values feed the QoS scores; there is no verification, benchmark, or proof-of-computation described.","fun_headline_variants_meta":{"raw":{"variants":["Blockchain crowdsources DRL training and models","Smart contracts power a DRL crowdsourcing marketplace","Crowdsourced DRL as a service on a blockchain","Trade DRL tasks and models via blockchain smart contracts"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000981,"raw_usage":{"total_tokens":4160,"prompt_tokens":933,"completion_tokens":3227,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":549,"completion_tokens_details":{"reasoning_tokens":3164}},"tokens_in":549,"tokens_out":3227,"duration_ms":22481,"temperature":1.0,"reasoning_tokens":3164,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T16:25:38.463420+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Let workers register with inflated hardware and model-environment claims, run the greedy allocation, and audit the actual resources and model metadata; if misreporting workers are selected and then fail to train or share usable models at the promised speed, the central claim that QoS metrics pick effective workers would be falsified. A cleaner test is to compare training outcomes and wall time for identical tasks allocated with truthful versus inflated profiles, holding everything else fixed.","supporting_citations":[{"cited_title":"Ribeiro, K","cited_arxiv_id":null,"evidence_quote":"Provides the architectural baseline for MLaaS that the paper argues is infeasible for DRL."},{"cited_title":"Alagha, S","cited_arxiv_id":null,"evidence_quote":"Defines the target localization multi-agent DRL environment used in the evaluation."},{"cited_title":"Nair, et al., Overcoming exploration in reinforcement learning with demon- strations, in: 2018 IEEE international conference on robotics and automation (ICRA), pp","cited_arxiv_id":null,"evidence_quote":"Supplies the demonstration-based learning motivation for why shared pre-trained models help DRL training."},{"cited_title":"Xidias, P","cited_arxiv_id":null,"evidence_quote":"Defines the fleet coordination environment used as one of the three DRL test applications."},{"cited_title":"Jiang, C","cited_arxiv_id":null,"evidence_quote":"Defines the multi-agent maze cleaning environment used in the training and recruitment experiments."},{"cited_title":"Abououf, S","cited_arxiv_id":null,"evidence_quote":"Supplies the reputation-based recruitment benchmark that the proposed QoS metric is compared against."},{"cited_title":"Alagha, R","cited_arxiv_id":null,"evidence_quote":"Provides the demonstration cloning method and expert-model assistance used to test the model sharing service."},{"cited_title":"Kadadha, H","cited_arxiv_id":null,"evidence_quote":"Offers a blockchain-based crowdsourcing implementation whose smart-contract gas cost is used as a benchmark."}],"review_version":1}