{"id":"8cb3ea7c-81bf-45d5-b069-53eb55a2af48","arxiv_id":"2505.24675","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"The proposed architecture uses Hyperledger Fabric and persistent identifiers to track provenance of scientific artifacts across federated institutions.","lead":"This paper describes a proposed architecture that uses a permissioned blockchain and persistent identifiers to track the origin and history of scientific data across collaborating institutions. Generalists might read it as an example of how blockchain is being positioned to address reproducibility and trust in federated research settings.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section III-B's 'computationally infeasible' tamper-resistance claim is unsupported for Hyperledger Fabric: it holds only under a governance assumption about honest ordering service, CAs, and endorsement policies, not as a cryptographic guarantee.","rationale":"The paper is a design proposal, not an implementation, and the abstract asserts guarantees that the body does not establish. The load-bearing security property is tamper-evidence and immutability. Permissioned blockchains like Hyperledger Fabric provide auditability against accidental modification, but not computational immutability against an adversary who controls the network's trust anchors. The text says trust is anchored 'not in a single entity but in a shared, append-only ledger' (Section III-B), yet Fabric has centralized components: the ordering service and root CAs are single trust anchors. Therefore the central claim rests on an unexamined governance assumption: that the consortium, its CAs, and its ordering service remain honest. This matches the reader's weakest_assumption. A formal threat model or an adversarial deployment test would settle the concern. Since the paper provides neither, the rejection is justified; my read does not change the verdict. I credit the paper for clear use cases and for explicitly stating that validation is ongoing, but those honest limitations do not support the guarantee language in the abstract and Section III-B.","tokens_in":11756,"tokens_out":3938,"duration_ms":52599,"concrete_test":"Deploy the proposed architecture on a two-organization Hyperledger Fabric network with the default Raft ordering service. Using one organization's admin certificate and a snapshot of the ordering service, fork the ledger from an earlier block, rewrite the HLF state for a previously committed PID (change its checksum or URI), and have a client query the fork. If the rewritten record is returned without an audit warning, Section III-B's 'computationally infeasible' claim is falsified under the stated permissioned settings. If the network resists, report under what policy and quorum conditions it did so.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the permissioned blockchain 'guarantees integrity, immutability, and auditability' and that 'tampering with historical data becomes computationally infeasible' (Section III-B). In Hyperledger Fabric, the hash chain makes tampering evident only if honest peers reject a forked or rewritten chain; it does not make rewriting computationally hard. The network's security rests on the Raft ordering service (or another non-BFT consensus), root certificate authorities, and endorsement policies. A compromised CA can mint identities; a colluding ordering service can reorder or fork; if enough peers accept the fork, history is changed. The paper neither specifies consensus, endorsement thresholds, nor a Byzantine adversary model, and it does not show how 'more organizations' improves robustness—Fabric robustness scales only with the policy-controlled quorum, not with participant count. Thus the claimed 'guarantee' is an organizational trust assumption, not a property of the technology. Separately, version linkage depends on the external PID service: the PID record is updated to point to the new provenance version, and a compromised PID record or unavailable resolver breaks the chain; the HLF transaction only records that an update happened. Without a threat model or formal analysis, the abstract's guarantee overclaims.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript proposes a modular architecture for tracking provenance of scientific artifacts across federated organizations. It combines a Hyperledger Fabric permissioned blockchain with persistent identifiers (PIDs) from the Handle/ePIC infrastructure, a client library, data and provenance servers, hashing software, and a versioning model in which PID records are updated to point to new versions of provenance documents. Five scientific use cases are described, covering climate data and AI forecasting, retraction propagation, iterative model development, post-publication artifact linking, and retrospective activity decomposition. The authors state explicitly that implementation details and performance benchmarks are deferred to future work. The central claim is that the architecture 'guarantees integrity, immutability, and auditability' and that 'tampering with historical data becomes computationally infeasible' (Section III-B).","tokens_in":11953,"tokens_out":6520,"duration_ms":79001,"significance":"If the claimed guarantees were established, the architecture would address a real need: long-term, cross-organizational provenance verification for data-intensive science, aligned with FAIR and TRUST principles. The design has sensible components, including direct client-to-ledger interaction that avoids a proxy bottleneck, invalidation rather than physical deletion of artifacts, and version chaining through PIDs that preserves history. The paper, however, provides no implementation, no machine-checked proofs, no formal adversary model, and no performance evaluation; the security and scalability properties are currently design hypotheses rather than demonstrated results. The modular decomposition and use-case framing may still serve as a useful blueprint for future systems work, provided the security claims are re-scoped and validated, and the authors deserve credit for making the deferred-validation status explicit in the text.","major_comments":[{"comment":"The statement that 'tampering with historical data becomes computationally infeasible' is not an accurate characterization of a permissioned Hyperledger Fabric deployment. With the default Raft ordering service, which is crash-fault tolerant rather than Byzantine-fault tolerant, a compromised ordering service can reorder or fork the chain, and a compromised certificate authority can mint valid identities. The hash chain makes tampering evident to honest peers, not computationally impossible. The paper does not specify the consensus algorithm, endorsement thresholds, or an adversary model, and the adjacent claim that robustness improves as more organizations join is only true if the endorsement policy and quorum are configured to scale accordingly. These qualifications should be incorporated into the abstract and Section III-B, replacing the unconditional 'guarantee' language with a governance-dependent tamper-evidence property.","section":"III-B, first paragraph"},{"comment":"The provenance versioning mechanism relies on updating the external PID record to point to the new version, while the Fabric chaincode only logs that an update operation occurred. If the Handle/ePIC resolver is compromised or unavailable, the version chain breaks, which also conflicts with the conclusion's claim that the system operates 'without introducing centralized points of failure.' Algorithm 1 checks authorization and increments the version but does not verify the new checksum against the new URI, does not check the integrity of the previous record, and does not specify what exactly the Fabric endorsement attests regarding the PID record update. The paper needs an explicit threat model for the PID service and a precise definition of the on-chain transaction's scope of proof.","section":"III-C, versioning and Algorithm 1"},{"comment":"The paper introduces five use cases but immediately states that implementation details and experimental benchmarks 'are not covered in this paper and will be discussed in detail in a future work.' The use cases are described as 'under development' and 'preliminarily demonstrated,' yet no demonstration results are reported. Without a prototype, performance measurements, or a formal analysis of failure modes, the abstract's claim to 'guarantee integrity, immutability, and auditability' is not supported. The authors should either add a preliminary evaluation or explicitly label these properties as design goals rather than established guarantees.","section":"IV, first paragraph"}],"minor_comments":[{"comment":"In the preconditions preceding Figure 3, 'HFL network' should be 'HLF network'.","section":"III-C, preconditions for Figure 3"},{"comment":"Figure 2's caption mentions a 'security infrastructure (green background)' but the text does not provide a legend or explanation of the color coding.","section":"Figure 2 caption"},{"comment":"Reference [15] (Greenspan, 'Do you really need a blockchain for that?') is cited among works presenting blockchain-based provenance solutions, but that essay critiques unnecessary blockchain use; please check the citation placement.","section":"II, blockchain-based provenance paragraph"},{"comment":"Section IV says the use cases were 'preliminarily demonstrated in a distributed setting' and also states that implementation details are not covered; please clarify what was actually demonstrated.","section":"IV, introductory paragraph"},{"comment":"In Algorithm 1, the variable 'permission' used by 'checkAuth' is not defined, and the unconditional 'newVersion <- version + 1' has no concurrency protection despite the sequence diagram implying an atomic update.","section":"Algorithm 1"}],"recommendation":"major_revision","confidential_remarks":"The paper is best read as a design/vision contribution rather than a validated systems paper. If the journal expects the security guarantee to be a central, established result, the current version is not acceptable; the authors should either re-scope the claims to governance-dependent tamper-evidence or include an implementation with measurements. The self-citations in [7] and [31] are background references and do not create circularity in the central argument."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is a clearly written design proposal for federated provenance tracking using Hyperledger Fabric, PIDs, and versioned invalidation. What is genuinely new is the combination: clients talk to the ledger directly (no proxy), version history lives in PID records, and invalidations propagate to downstream artifacts. The use cases (climate data, model retraining, post-publication enrichment) are sensible, and the writing is honest about the fact that there is no implementation yet.\n\nThe soft spot is the guarantee language. The abstract says the architecture 'guarantees integrity, immutability, and auditability,' and Section III-B says tampering with historical data becomes 'computationally infeasible.' For Hyperledger Fabric that is not right. The hash chain makes tampering evident only if honest peers reject a rewrite; it does not make rewriting computationally hard. Security rests on the ordering service (typically Raft, not BFT), the certificate authorities, and endorsement policies. A compromised CA or colluding quorum can change history. So the claim is a governance assumption, not a property of the technology. The paper also says 'as more organizations participate, robustness improves,' which conflates participant count with policy-controlled quorum. In Fabric, adding organizations without quorum weight does nothing.\n\nThe versioning via PID records is a nice idea, but it has a second-order trust anchor: the PID resolver (Handle/ePIC) must stay authoritative and uncompromised. The blockchain only records that an update happened; it does not secure the linkage itself. The conclusion's claim of 'no centralized points of failure' also glosses over the PID service and the ordering service as centralized components.\n\nThere is no threat model, no performance numbers, and no prototype. The authors say so in Section IV: 'implementation details... will be discussed in detail in a future work.' So as a research result, the paper is unvalidated. As a design document, it is plausible and readable.\n\nI agree with the reader on the core issue: the gap between the abstract's guarantee and the evidence is load-bearing. That said, the paper is not careless. It scopes the future work and the architecture is coherent. If the authors reframe the claims as 'tamper-evident under specified governance assumptions' and add a concrete threat model, this could become a useful blueprint. For now I would not cite it as a validated system, but I would send it to review if the venue tolerates design papers, because the integration problem is real and the authors are credible. My recommendation: treat it as a position paper and ask for a careful revision that aligns claims with what permissioned blockchains actually provide.","headline":"Plausible design proposal for federated provenance tracking, but the abstract overclaims what permissioned blockchain can guarantee without a prototype or threat model.","tokens_in":12498,"tokens_out":2452,"would_cite":false,"duration_ms":29803,"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":"The paper proposes a modular architecture that records scientific provenance on a permissioned blockchain, giving federated collaborations a tamper-evident and independently verifiable audit trail.","keywords":["provenance","federated science","permissioned blockchain","Hyperledger Fabric","persistent identifiers","auditability","reproducibility"],"falsifier":"A direct test would be to run a small permissioned network with a colluding subset of peers and an attacker-controlled ordering service, then attempt to rewrite a provenance record after commit and check whether any client or auditor can detect the change; if the ledger accepts the altered history, the tamper-evidence claim fails. A second test: measure end-to-end update latency as the number of participating organizations grows, and see whether it stays within the bounds scientific workflows can tolerate.","tokens_in":11546,"feed_emoji":"🔗","tokens_out":6325,"duration_ms":70618,"temperature":0.7,"pith_summary":"The paper proposes a modular, domain-agnostic architecture that records scientific provenance on a permissioned blockchain, so that every assertion about an artifact is time-stamped, tamper-evident, and independently verifiable across institutions. It claims this removes the need for a single trusted central authority while keeping overhead below public-blockchain approaches, and it anchors artifact identity in persistent identifiers that also carry provenance version history. The authors argue this combination supports long-term auditability, cross-organization reproducibility, and propagation of corrections and retractions. Five use cases, from climate-data AI forecasting to post-publication enrichment, illustrate the intended behavior; implementation and benchmarks are planned future work.","feed_headline":"Federated science gets a tamper-evident provenance trail","feed_subtitle":"A modular architecture anchors artifact history on a permissioned ledger so multi-institution results stay verifiable.","key_machinery":"The central mechanism is the blockchain-anchored provenance document with PID-based versioning. A provenance document is published with a persistent identifier; when a new version is created, the PID record of the previous version is updated to reference the new one, and the publication is logged on the permissioned ledger via a chaincode function (a blockchain smart contract) that checks authorization, bumps the version counter, and stores the new URI and checksum. The append-only ledger provides tamper-evidence and time-stamping, while the PID record provides stable, resolvable linkage across experiments and versions. A client library that submits transactions directly to the network, without an intermediary, is what keeps trust anchored in the ledger rather than in any single server.","core_discovery":"The paper's central claim is that trustworthy provenance in federated science can be achieved by making the provenance record itself live on an append-only permissioned ledger, specifically Hyperledger Fabric, while using persistent identifiers (PID records) as the stable reference that links artifact versions. Each provenance publication or update is a blockchain transaction authenticated by the client's certificate; updates are only allowed to append a new version, never to overwrite or delete, and even artifact deletion is implemented as invalidation to preserve the audit trail. Because clients talk directly to the ledger rather than through a proxy, there is no central point of failure that could filter or falsify records, and a read-only organization lets external consumers verify queries without write access. The authors present this as a response to six concrete challenges, including cross-experiment artifact tracking, long-term temporal reliability, version linkage, correction propagation, accountability, and the vulnerabilities of centralized mutable provenance stores.","pith_inferences":["The same architecture could be extended to enforce data-usage policies by encoding license terms in provenance records and checking them at query time, which would go beyond the paper's focus on integrity and auditability.","Since version linkage lives in the PID record, the system's long-term guarantees depend on the PID provider staying authoritative; a natural hardening step, not discussed in the paper, would be to log every PID update itself as a blockchain transaction.","The permissioned design means 'immutable' is a governance property: a colluding set of the consortium's own peers could potentially rewrite the ledger, so the guarantee should be understood as protection against outsider tampering rather than against insider collusion.","A testable prediction of the architecture is that its update latency will be dominated by the endorsement and ordering phases of the permissioned ledger, so performance studies across federation sizes would reveal whether the design scales to the big-data workloads it targets."],"forward_implications":["If a published dataset is retracted, downstream artifacts that used it can be automatically flagged as affected, because the provenance graph records every derivation.","A reader of a publication can trace a result image back to its training model, training dataset, and raw measurements using the persistent identifiers, enabling full reproducibility checks.","Provenance records cannot be silently altered or deleted: every update creates a new version and logs the operation, so old records remain available for dispute or auditing.","Because no proxy mediates blockchain access, the system remains usable for verification even if an individual data server goes offline, and records remain attributable to their signing users."],"supporting_citations":[{"why":"Supplies the FAIR principles that the architecture is designed to satisfy and the motivation for rich, verifiable metadata.","marker":"[40]"},{"why":"Describes an existing blockchain-based provenance system (Hyperprov) that the paper positions as lacking a federated, cross-organization perspective, motivating the proposed design.","marker":"[38]"},{"why":"Shows a permissioned-blockchain provenance approach with a two-transaction protocol; the paper contrasts its lack of federated governance and reproducibility focus.","marker":"[9]"},{"why":"Provides the performance evaluation of permissioned blockchain platforms that supports the choice of Hyperledger Fabric over public ledgers.","marker":"[25]"},{"why":"Compares Ethereum, Hyperledger Fabric, and Corda, informing the selection of permissioned infrastructure.","marker":"[39]"},{"why":"Defines the W3C PROV provenance family, the standard provenance model the architecture aligns with for interoperable records.","marker":"[27]"}],"fun_headline_variants":["Blockchain anchors provenance for federated science data","Append-only ledger keeps scientific provenance tamper-evident","Modular blockchain architecture tracks artifact history across institutions","Permissioned blockchain secures provenance in multi-site research","Hyperledger-based provenance trail for distributed science"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole design assumes the group running the blockchain is trustworthy enough not to collude in rewriting records, and that the identifier service stays reliable and authoritative.","fun_headline_variants_meta":{"raw":{"variants":["Blockchain anchors provenance for federated science data","Append-only ledger keeps scientific provenance tamper-evident","Modular blockchain architecture tracks artifact history across institutions","Permissioned blockchain secures provenance in multi-site research","Hyperledger-based provenance trail for distributed science"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000144,"raw_usage":{"total_tokens":1138,"prompt_tokens":872,"completion_tokens":266,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":488,"completion_tokens_details":{"reasoning_tokens":192}},"tokens_in":488,"tokens_out":266,"duration_ms":3599,"temperature":1.0,"reasoning_tokens":192,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T12:15:44.274729+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A direct test would be to run a small permissioned network with a colluding subset of peers and an attacker-controlled ordering service, then attempt to rewrite a provenance record after commit and check whether any client or auditor can detect the change; if the ledger accepts the altered history, the tamper-evidence claim fails. A second test: measure end-to-end update latency as the number of participating organizations grows, and see whether it stays within the bounds scientific workflows can tolerate.","supporting_citations":[{"cited_title":"Wilkinson, Michel Dumontier, IJsbrand Jan Aalbersberg, Gabrielle Appleton, Myles Axton, Arie Baak, Niklas Blomberg, Jan- Willem Boiten, Luiz Bonino da Silva Santos, Philip E","cited_arxiv_id":null,"evidence_quote":"Supplies the FAIR principles that the architecture is designed to satisfy and the motivation for rich, verifiable metadata."},{"cited_title":"HyperProv: Decentralized Resilient Data Provenance at the Edge with Blockchains","cited_arxiv_id":"1910.05779","evidence_quote":"Describes an existing blockchain-based provenance system (Hyperprov) that the paper positions as lacking a federated, cross-organization perspective, motivating the proposed design."},{"cited_title":"Provenance metadata management in distributed storages using the hyperledger blockchain platform","cited_arxiv_id":null,"evidence_quote":"Shows a permissioned-blockchain provenance approach with a two-transaction protocol; the paper contrasts its lack of federated governance and reproducibility focus."},{"cited_title":"Performance evaluation of permissioned blockchain platforms","cited_arxiv_id":null,"evidence_quote":"Provides the performance evaluation of permissioned blockchain platforms that supports the choice of Hyperledger Fabric over public ledgers."},{"cited_title":"Valenta and S","cited_arxiv_id":null,"evidence_quote":"Compares Ethereum, Hyperledger Fabric, and Corda, informing the selection of permissioned infrastructure."},{"cited_title":"PROV-Overview: An Overview of the PROV Family of Documents","cited_arxiv_id":null,"evidence_quote":"Defines the W3C PROV provenance family, the standard provenance model the architecture aligns with for interoperable records."}],"review_version":1}