Model Procurement for Industrial Cyber-Physical Systems Using Cryptographic Performance Attestation

Abstract

Integrating third-party Machine Learning (ML) models into industrial Operational Technology (OT) creates a procurement deadlock: operators cannot verify vendor performance claims without sharing representative evaluation data with vendors, while vendors refuse to reveal proprietary model weights before purchase, rendering traditional safeguards such as Non-Disclosure Agreements technically unenforceable. This paper introduces a framework combining Zero-Knowledge Proofs (ZKPs) with smart contracts to enable trust-minimized, cryptographically verifiable competitive model procurement in Industrial Cyber-Physical Systems (ICPS). Vendors cryptographically prove that their model outperforms a legacy baseline without disclosing proprietary weights, a process we term cryptographic performance attestation, while the on-chain workflow automates escrow, proof verification, and best-vendor selection with arbiter-based dispute resolution. ZKP privacy is scoped to vendor model weights; operator-side evaluation-data confidentiality is managed separately via synthetic, de-identified, or public benchmark data. We analyze three ZKP workflow variations and evaluate them on consumer-grade hardware, achieving proving times of approximately three seconds and sub-dollar on-chain verification costs under Layer-2 fee assumptions for the recommended single-proof variation, while identifying computational trade-offs of recursive proof aggregation. The entire verification phase operates offline with no impact on real-time OT control paths, bridging the IT/OT pre-transaction trust gap while deferring artifact deployment to existing OT tooling.

1. Introduction

Industry 4.0 has become an important part of the industrial sector, characterized by the convergence of Information Technology (IT) and Operational Technology (OT). This integration promises significant efficiency gains through advanced analytics, predictive maintenance, and autonomous control [1]. However, bridging the gap between IT innovation and OT reliability remains a challenge. OT environments, managing critical infrastructure like power grids, manufacturing plants, and transportation systems, prioritize safety, availability, and real-time performance above all else. In contrast, the rapid pace of software innovation and machine learning (ML) workloads deployed through IT stacks often introduces security vulnerabilities and “black-box” unpredictability that are unacceptable in high-stakes industrial settings.

A critical friction point arises when Industrial Operators (the OT side) seek to upgrade their legacy control or monitoring systems with state-of-the-art ML algorithms developed by external IT vendors. Operators may be hesitant to share high-frequency, sensitive sensor telemetry with third parties due to data privacy regulations and trade secret concerns. Conversely, IT vendors (Model Providers) may be reluctant to share proprietary details or sensitive artifacts due to intellectual property (IP)/business-secret and competitive-advantage concerns [2]. Once a model is purchased and deployed, the Operator necessarily gains full access to its parameters, a fundamental trade-off inherent to local inference. However, before this transaction occurs, vendors need assurance that their IP won’t be exposed prematurely to unqualified bidders or disclosed publicly during competitive bidding processes. Our framework resolves this procurement deadlock asymmetrically: ZKPs address vendor-side IP exposure and computation integrity cryptographically, while operator-side data confidentiality remains an orthogonal dataset-governance concern handled through the choice of synthetic, de-identified, or public evaluation data during procurement.

Traditional solutions to this “trust gap” rely on legal frameworks like Non-Disclosure Agreements (NDAs) or trusted third-party audits [3]. These methods are legally binding but technically unenforceable in real-time; they do not mathematically guarantee that a specific model was used to generate a specific prediction.

Furthermore, as industrial systems become more autonomous, the need for automated, cryptographic verification of ML model evaluation and performance claims prior to deployment becomes paramount to reduce the risk of supply chain attacks and regression-related operational failures [4,5].

Zero-Knowledge Proofs (ZKPs) offer a compelling technical solution to this dilemma. ZKPs allow a “Prover” (the IT Vendor) to cryptographically convince a “Verifier” (the OT Operator) that a computation (inference or training) was performed correctly according to a specific, agreed-upon model, without revealing the model’s internal parameters (the private witness in the ZKP circuit) [6]. In our framework, the evaluation dataset is a public input to the circuit; ZKP data-hiding applies to the private witness, i.e., the vendor’s model weights. Accordingly, the framework cryptographically protects vendor-side model confidentiality, while any confidentiality requirement on the evaluation dataset must be managed operationally through data selection and handling practices outside the ZKP itself. When combined with blockchain smart contracts, this enables a trust-minimized framework for Verifiable Cyber-Physical Systems (CPS), where model upgrades and performance claims can be validated on-chain before deployment. Throughout this paper, we use trust-minimized to mean that correctness and integrity claims are enforced cryptographically.

This paper explores the application of ZKPs and blockchain to create a pre-deployment verification/approval gate for model updates in Industrial Iternet of Things (IIoT). We present a framework where third-party vendors can prove the superior performance of their predictive maintenance models against a baseline using historical telemetry, without exposing their IP; on-chain, the workflow can be instantiated so that only commitments and agreed metric outputs are revealed. This does not mean that evaluation data is hidden from participating vendors: in the intended procurement workflow, operators use representative synthetic data, de-identified samples, or public benchmarks when confidentiality constraints prohibit sharing raw OT telemetry. Beyond verification, the system instantiates a competitive procurement workflow: multiple vendors can submit verifiable bids before a deadline, and the smart contract automatically filters invalid submissions, selects the best verified improvement, and releases escrowed funds according to the outcome. Because participation is mediated by public on-chain transactions, the same interface could in principle be used by automated software agents acting on behalf of organizations. Secure delivery and installation of the winning artifact are treated as separate concerns handled by established Over-The-Air (OTA) and OT change-management processes.

Crucially, this architecture maintains a strict temporal and logical separation between the verification phase and the execution phase: the blockchain and ZKP logic operate exclusively as an offline procurement-time gate, requiring no connectivity or computational overhead within the real-time OT control path.

1.1. Motivation

The convergence of IT and OT in critical infrastructure offers immense value but is hampered by a procurement-time trade-off between verifiable evaluation, vendor IP protection, and operator-side data-handling constraints [1,2,3,6]. Consider the following industrial predictive maintenance scenario:

• An OT Operator (Asset Owner) manages a fleet of legacy industrial assets (e.g., turbines, pumps) generating high-frequency vibration data. They want to detect anomalies earlier to prevent downtime but lack internal ML expertise.
• IT Vendors (ML Service Providers) possess advanced deep learning models capable of detecting these subtle anomalies. However, they treat their model architectures and weights as high-value Trade Secrets.

• Current procurement approaches create a deadlock. For the Operator to objectively compare competing models, vendors would traditionally need to share model artifacts or grant evaluation access, exposing proprietary architectures and trained weights to parties who may never purchase the solution. Conversely, if vendors withhold their models until after payment, the Operator must rely on unverified performance claims supported only by contractual assurances (NDAs, service-level agreements) and optional third-party audits, mechanisms that are legally binding but not cryptographically enforceable, cannot readily scale to open multi-vendor competition, and offer no automated guarantee that a specific model produced a specific evaluation result on agreed data.

This research is motivated by the potential to leverage ZKP systems, such as EZKL [7], and blockchain state management (MUD framework [8]) to break this procurement-phase deadlock. We propose a system where:

• Pre-Deployment IP Protection: IT Vendors can prove their model’s performance (e.g., “Accuracy > 95%” or “Loss < 0.1”) on a representative dataset cryptographically during the procurement phase, without revealing the model weights to competitors or the public blockchain. This prevents premature disclosure to parties who ultimately do not purchase the solution.
• On-Chain Data Minimization: The on-chain workflow stores only compact commitments (hashes) and agreed metric outputs, not raw datasets. Evaluation data is provided to vendors out-of-band, either as a representative sample, a synthetic dataset generated by the Operator, or a public benchmark. This is an engineering property that reduces on-chain storage costs and avoids unnecessary data publication; it is not a data-confidentiality guarantee, as vendors necessarily receive the evaluation data to perform inference and generate proofs. This framework therefore addresses vendor-side IP protection through cryptographic means, while operator-side evaluation-data confidentiality is managed through data selection (synthetic, de-identified, or public benchmark datasets), not by ZKP directly.
• Verifiable Performance Claims: The Operator deposits funds into escrow at job creation. Escrowed funds are released to the winning Vendor only after on-chain ZKP verification confirms that the submitted model meets the specified performance baseline, and only if the Operator does not successfully dispute the result. This ensures the Operator never pays for an unverified claim, while the escrow mechanism commits credible demand.
• Automated Procurement: Smart contracts automate the procurement lifecycle by managing escrow, enforcing submission deadlines, selecting the best verified submission, and governing fund release or withdrawal, thereby reducing reliance on manual oversight or legal enforcement.

Critically, this framework addresses the pre-transaction trust gap, not post-deployment model extraction. Once an Operator purchases and deploys a model, they necessarily have full access to its parameters for local inference; our system does not (and cannot, with current cryptographic primitives) prevent reverse engineering at that stage. Instead, we ensure that sensitive IP is only revealed to the winning bidder who pays for it, rather than being exposed to all participants or leaked during competitive evaluation.

1.2. Contributions

This paper makes the following key contributions:

• Novel Framework Proposal: We propose a novel framework architecture that integrates Zero-Knowledge Proofs with blockchain technology to enable trust-minimized, vendor-IP-protecting, and verifiable competitive procurement of machine learning models.
• We defined an industrial procurement use case and designed workflows intended to (i) accelerate competitive model procurement and reduce reliance on slow, trust-heavy mechanisms such as NDAs, manual audits, and ad hoc benchmarking, and (ii) protect both sides of the transaction: OT Operators against economic harm (e.g., paying for unverified regressions or malicious submissions) and IT Vendors against premature IP disclosure during bidding.
• We analyze three distinct ZKP workflow variations tailored for this use case, evaluating their inherent trade-offs concerning model-IP privacy guarantees, verification complexity, computational overhead, and potential for decentralization. We justify the selection of one specific variation for our Proof of Concept (PoC) implementation based on this analysis.
• Performance and Cost Evaluation: We provide an initial quantitative evaluation of the implemented solution. This includes measuring ZKP generation times, proof sizes, and the gas costs associated with key on-chain interactions (job creation, proof of improvement submission/verification, dispute handling) under defined experimental scenarios, offering insights into the system’s practical viability and potential bottlenecks.

2. Related Work

This section surveys the existing literature and projects relevant to the proposed framework for verifiable, vendor-IP-protecting model upgrades in Industrial Cyber-Physical Systems (ICPS). We examine prior work in Industrial IoT security, decentralized computing, and the growing field of Zero-Knowledge Machine Learning (ZKML).

Trust in Industrial IoT and OT environments has traditionally relied on perimeter security and trusted supply chains. However, the move towards Industry 4.0 and the integration of third-party ML solutions challenges this model. “Zero Trust” architectures for IoT suggest continuous verification of all assets, but mostly focus on network identity rather than computational integrity [9]. Verifiable computing in industry often leverages hardware-based Trusted Execution Environments (TEEs) like Intel SGX or ARM TrustZone to secure code execution [10]. While effective, TEEs rely on the manufacturer’s root of trust and are vulnerable to side-channel attacks. Furthermore, TEEs do not inherently provide succinct proofs of model performance that can be efficiently verified by a low-power edge device or a smart contract without re-execution.

In the context of collaborative maintenance and software supply chains, ensuring the integrity of updates is critical. Current “Over-The-Air” (OTA) update mechanisms in automotive and industrial sectors use digital signatures to prove origin (who signed it) but do not provide cryptographic evidence about pre-deployment evaluation claims (e.g., how a model scores on an agreed test and metric) [11]. Our work addresses this gap by using ZKPs to cryptographically certify a model’s evaluation result prior to deployment; secure distribution, installation, rollback, and endpoint attestation are assumed to be provided by existing OTA tooling.

Furthermore, the rise of multi-agent systems (MAS), powered by Large Language Models (LLMs) [12,13,14], introduces new collaborative paradigms for tasks like software development and even science. In industrial settings, similar agentic systems could support coordination tasks such as maintenance planning, incident triage, and supply-chain remediation. As these autonomous agents increasingly participate in procurement, optimization, and coordination workflows, the need for trust-minimized agent-to-agent collaboration becomes critical: agents operated by different organizations (or no organization at all) must transact and make commitments without the slow overhead of NDAs, legal review, or manual verification. Our framework can serve as infrastructure for such collaboration, providing an auditable procurement-time verification gate for agent- or human-produced ML artifacts before OT deployment, where on-chain commitments and ZKP-verified claims substitute for traditional trust mechanisms. However, establishing trust in agentic systems presents challenges, as verification often relies on evaluation of the final output, rather than cryptographically proving the integrity of individual contributions during the process. This is particularly problematic in open, decentralized settings where autonomous agents might collaborate, necessitating frameworks that can ensure trust and fair rewards.

Decentralized computing platforms offer peer-to-peer sharing of computational resources as alternatives to traditional cloud services [15,16]. They primarily provide resource-sharing platforms for computation, verifying task completion mainly for billing purposes. While some platforms are incorporating enhanced privacy and Proof-of-Execution, their core function remains resource provision. However, they verify agreement on scheduling decisions, not the correctness of computations. Other approaches [10,17] leverage hardware-based Trusted Execution Environments (TEE) to provide attestations about computation occurring within a secure enclave, relying on trust in the hardware manufacturer and TEE integrity.

Our framework differs fundamentally from these approaches. It is not primarily a compute-brokering platform nor a resource coordination system, nor does it rely on hardware attestations (like TEE-based systems). We utilize ZKPs not just to prove computation happened, but to cryptographically verify specific, qualitative properties of the computational result, namely, that an ML model demonstrates a proven performance improvement relative to a baseline using mathematical trust assumptions and without revealing the underlying model IP.

Zero-Knowledge Proofs have been increasingly explored to address critical trust, privacy, and integrity issues prevalent in machine learning workflows. Key challenges arise in Machine Learning as a Service (MLaaS), where users need assurance about model usage and correct execution by the provider, and the privacy of their inference data must be protected. Similar challenges exist in distributed or federated learning (FL) scenarios, where trusting participants’ computations and contributions is essential [18,19]. ZKPs offer a powerful mechanism to verify computations without revealing sensitive underlying data, such as model weights or training inputs.

A significant body of work focuses on proving the correct execution of ML model inference (i.e., proving y = f(x,w) was computed correctly) without revealing the model weights w [18]. Research has progressed from early interactive proof systems to more efficient non-interactive methods using ZeroKnowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) and Scalable Transparent Arguments of Knowledge (zk-STARKs) applicable to diverse model types, including Convolutional Neural Networks (CNNs), decision trees, and even Large Language Models (LLMs) [20]. Frameworks like those described by Lu et al. focus on optimizing proofs, particularly for complex non-linear layers often found in NNs, by converting operations into more efficient range and exponent relations provable via ZKPs [21]. Others, like the system detailed by South et al., leverage zk-SNARKs to create verifiable evaluation attestations, proving that a model with specific (hashed) private weights achieves certain performance or fairness metrics on public datasets, allowing future inferences to be checked against the attested model weights [22].

Verifiable training aims to prove adherence to specific training algorithms or dataset properties, which is particularly crucial for ensuring integrity in Federated Learning (FL) settings [18]. In FL, where clients train models locally on private data, ZKPs can protect the privacy of client updates while assuring the central aggregator of their validity or integrity. Systems like VPFL [23] use ZK-range proofs to ensure local model parameter updates stay within reasonable bounds, while approaches like RiseFL [24] employ probabilistic ZKP checks for integrity verification to reduce computational overhead. Addressing potential manipulation by the central aggregator itself, zkFL [25] uses ZKPs to force the aggregator to prove it correctly aggregated the client updates it received. These applications highlight the versatility of ZKPs in enhancing trust and transparency in decentralized learning environments. However, efficiently generating ZKPs for complex ML operations, especially non-linear functions and large models, remains a significant challenge, driving research into optimized circuits, novel proof techniques, and specialized ZKP systems.

Our proposed framework builds on these concepts by integrating ZKPs (specifically via EZKL [7,22], which supports generating proofs for diverse models) with smart contracts tailored for competitive procurement of ML models. While related works focus on verifying inference or training integrity, our work differs by addressing the competitive procurement phase, providing a framework specifically for verifying relative performance improvements of third-party models before they are purchased and deployed into restricted OT environments.

3. Proposed System

This section details the architecture and workflow of our proposed system designed to facilitate trust-minimized, vendor-IP-protecting, and verifiable competitive procurement of machine learning models. By combining Zero-Knowledge Proofs for computational integrity and IP protection with smart contracts for state management and orchestration, we create a decentralized environment where OT Operators can securely solicit model upgrades from IT Vendors.

3.1. System Overview

The primary goal is to establish a decentralized framework for trust-minimized, incentivized model upgrades in Industrial IoT, addressing the “Privacy–Verification Trade-off” in OT/IT convergence. The system is architected as an out-of-band verification layer. It does not participate in real-time control or sensing; instead, it provides a trust-minimized environment for the procurement and approval of model artifacts. The actors are set out below:

• OT Operators (Asset Owners): Entities managing physical industrial assets (e.g., turbines, grids). They define the maintenance problem, provide baseline historical data (or its hash), and fund the reward.
• IT Vendors (Model Providers): Specialized ML firms or freelance data scientists. They develop superior predictive models off-chain, generate ZKPs to prove performance, and submit tamper-evident on-chain solution identifiers (e.g., a content address or handle pointing to the off-chain artifact).
• Arbiters (Auditors): Designated neutral parties or automated oracles responsible for resolving disputes, particularly verifying that a revealed solution matches the performance and the cryptographic commitment if an Operator claims it is invalid.

The workflow operates as follows: An OT Operator initiates a “Model Upgrade Request” by creating a new job via the deployed smart contracts, specifying job parameters such as a baseline performance metric and threshold (e.g., a target loss value), a commitment to the evaluation dataset, submission deadlines, and the reward amount, while depositing funds into escrow. IT Vendors work off-chain to train better models. To bid, a Vendor generates a ZKP proving that their proprietary model achieves a better loss metric (e.g., lower MSE) than the baseline, without revealing the model weights. This “Proof of Improvement” is verified on-chain. After the bidding period, the smart contract selects the best verified Vendor. This winner then submits a solution identifier on-chain; the model artifact itself is exchanged off-chain and may be encrypted in transit or at rest depending on the deployment. The Operator downloads and verifies the model locally. If the model performs as promised, the reward is released. If the Operator disputes the submitted model, the dispute resolution process allows Arbiters to verify the claim against the on-chain commitments.

3.2. System Architecture and Implementation

The system architecture consists of two subsystems (off-chain and on-chain). It combines off-chain computation for model development and proof generation with on-chain logic for state management, verification, and workflow orchestration.

3.2.1. CPS Integration Architecture

Before detailing the off-chain and on-chain subsystems, we contextualize how the proposed procurement-time verification workflow fits into an Industrial Cyber-Physical Systems (ICPS) setting. Figure 1 provides a simplified, phase-oriented view that highlights trust boundaries (IT network, IT/OT DMZ boundary, and the OT security perimeter). It is intentionally not a full OT reference architecture.

The integration can be seen as three temporal phases:

Phase 1: Competitive procurement (in scope). An OT Operator (buyer) publishes a job and evaluation parameters, and IT Vendors submit Zero-Knowledge Proofs attesting that a candidate model satisfies the agreed evaluation relation (e.g., achieves a lower loss than a baseline) without revealing proprietary parameters. The blockchain acts as a public trust anchor and audit log: it verifies proofs, records submissions, and finalizes winner selection. The on-chain state contains compact identifiers (e.g., commitments/hashes and solution handles), not raw OT telemetry and not runtime control traffic.

Phase 2: Secure deployment preparation (out of scope). In an ICPS deployment, an OT Gateway placed in or near the DMZ can read chain state (e.g., polling for the winning bid and its solution identifier) and trigger internal change-control steps such as staging, approval, and artifact retrieval through operator-controlled channels. Importantly, this pattern does not require inbound connectivity from the public blockchain into the OT control zone; the OT side can maintain strict zone isolation while still consuming the procurement outcome.

Phase 3: Runtime execution (out of scope). The OT Edge controller (PLC/RTU/industrial PC) runs the already-approved model locally. Note that we do not claim runtime attestation or continuous monitoring of inference correctness; the contribution is a pre-deployment verification/approval gate.

This phase-oriented view addresses key industrial concerns:

• Network segmentation and zone isolation: OT integration can be implemented as read-only consumption of chain state from a DMZ gateway, with the actual update crossing the OT security perimeter only during controlled maintenance windows.
• Legacy compatibility: PLCs/RTUs do not need blockchain clients or ZKP verifiers; cryptographic verification occurs during procurement, while deployment uses standard OT change-management procedures.
• Auditability: Proof verification results, winner selection, and dispute events are recorded on-chain as a tamper-evident procurement log (without exposing raw OT telemetry).

Regarding fail-safe behavior, the architecture is intentionally designed so that the blockchain is never part of the real-time control path. OT Edge controllers continue operating with the last locally approved and installed model configuration regardless of chain connectivity. If the chain becomes temporarily unreachable, the procurement phase is paused until connectivity is restored and no new model updates are authorized, but already deployed models continue operating normally. The OT Gateway should therefore maintain a local cache of the last confirmed chain state so that it can resynchronize cleanly once connectivity returns. This separation is consistent with IEC 62443 zone/conduit principles [26,27]: chain unavailability affects only the procurement layer at the IT/OT boundary and does not propagate as a fault into the OT control zone.

The subsequent subsections detail the off-chain computation and the on-chain workflow that implement the Phase 1 procurement-time verification.

3.2.2. Off-Chain Subsystem

The off-chain component is primarily handled by the IT Vendor and involves ML model development alongside ZKP creation. IT Vendors utilize standard ML frameworks for model development. For our research, we focused on time series forecasting using an ARIMA (AutoRegressive Integrated Moving Average) model, implemented in PyTorch (v2.6.0).

To implement our chosen ZKP approach (Variation 1, detailed in Section 3.4), the necessary computations (core model inference, performance evaluation, and baseline comparison) must be defined together. Figure 2 visually depicts the structure of this combined computation. As shown, it takes public inputs like the test data and the baseline loss ($BL$). Internally, it first executes the ML model which produces the results (R), then calculates the performance metric (e.g., Mean Squared Error) resulting in the loss (L), and finally compares this loss (L) against the job’s baseline loss ($BL$) to determine if an improvement was achieved (outputting a True/False flag). This integrated structure thereby proves not only the model’s output but also its satisfaction of the improvement criteria within a single proof. Practically, this involved first defining the complete sequence of operations (ARIMA inference, loss calculation, comparison) within PyTorch. This combined PyTorch model, representing the desired computational graph, is exported to the Open Neural Network Exchange (ONNX) format.

Subsequently, the EZKL library is employed client-side. The exported ONNX file is compiled into a ZKP circuit compatible with the underlying proving system (Halo2). This system relies on KZG polynomial commitments (Kate–Zaverucha–Goldberg commitment scheme) to handle the core cryptographic binding of the computation’s execution trace (witness). Following this compilation, the setup phase is performed (generating proving and verification keys specific to this circuit structure) and then a proof is generated.

This process yields a zk-SNARK, ${\pi }_1$. This proof attests to the integrity of the entire computation represented by the circuit. Specifically, it cryptographically verifies that:

1.

Executing the circuit logic (model inference, loss calculation, comparison) on the public inputs (test data, baseline loss $BL$) using the IT Vendor’s private model parameters correctly produces the claimed public outputs (the new loss L, the improvement flag).

2.

A Poseidon hash, computed within the circuit over the private model parameters, matches a specific public hash value supplied as a public instance of the proof. This acts as the commitment to the parameters, ensuring the IT Vendor cannot later submit a different model while allowing the OT Operator or arbiters to verify solution authenticity against this public hash.

EZKL also facilitates the generation of the specific Solidity Verification Key Artifact (VKA) for the circuit, which is a small contract containing the Verification Key (VK) for a particular ZKP circuit and associated metadata. This allows a single, reusable verifier contract to validate a proof against a referenced VK without deploying a full, unique verifier for each improvement (gas cost savings). In the PoC, the reusable verifier contract takes the VKA address provided by the IT Vendor as an argument during verification. Importantly, this means on-chain verification checks computational correctness with respect to the circuit identified by that VKA (i.e., the proof satisfies the relation encoded by that circuit), but it does not by itself guarantee that the circuit corresponds to a job-mandated evaluation semantics (e.g., the intended loss definition, data-window commitment binding, or baseline binding). In Variation 1, binding to the intended evaluation semantics is enforced operationally via the OT Operator’s off-chain solution validation (including checking the parameter-hash commitment) and, if required, the dispute process in which arbiters can review evidence and adjudicate circuit substitution or other qualitative mismatches.

3.2.3. On-Chain Subsystem

The on-chain subsystem orchestrates the collaborative workflow, enforces rules, and ensures the integrity of the process. The executable logic is primarily encapsulated within three main smart contracts that govern the core business operations:

• Job Contract: This contract is responsible for managing the lifecycle of a job, including its creation, handling the escrow deposit and management, enforcing deadlines, and controlling the final release or withdrawal of funds.
• Improvement Contract: This contract manages the proof of improvement submissions. It triggers the ZKP verification process, keeps track of the best valid submission received for a job, and handles the final submission of the actual solution by the winning IT Vendor.
• Dispute Contract: This contract governs the dispute resolution process. Its responsibilities include managing arbiter registration, handling the initiation of disputes, overseeing the arbiter voting logic, and executing the final resolution based on the vote outcome.

The system’s state and overall orchestration leverage the MUD v2 framework’s Entity Component System (ECS) paradigm. In this model, core concepts such as Jobs, Improvements, and Arbiters are represented as unique identifiers termed Entities. The state associated with these entities is managed through various Components, which are implemented as on-chain tables. Key tables in this implementation include $JobCore$ (tracking essential job state like ID, creator, status, the ID of the best improvement, escrow status, and timestamp), $JobDetails$ (storing job-specific parameters like the test data hash, baseline loss, metric type, model hash, requirements hash, and reward amount), $JobDeadlines$ (holding the crucial timestamps for submission and decision deadlines), $Improvements$ (containing data related to each proof of improvement submission such as its ID, the associated job ID, the claimed new loss, the IT Vendor’s address, the VKA address, the proof hash, a commitment to the parameters used, and a submitted solution identifier stored as a dynamic bytes field), and $Disputes$ (managing the state of any disputes, including the job ID, resolution status, evidence hash, assigned arbiter IDs, and their votes). To minimize transaction costs, the PoC stores compact identifiers (e.g., 32-byte handles) on-chain rather than full model artifacts; the on-chain workflow additionally emits a $keccak256\left(solution\right)$ hash in the solution submission event to provide a fixed-size integrity reference. In a production deployment, the solution identifier would typically be a content address (e.g., an IPFS CID) or cryptographic hash pointing to off-chain storage.

For on-chain proof verification, the Improvement System interacts with a verifier wrapper contract. This wrapper calls a generic Halo2 [28] Verifier contract using the VKA contract address provided by the IT Vendor for their submission. Successful verification validates the ZKP against the VK referenced by that VKA and allows the system to extract crucial public outputs, such as the claimed performance metric and the Poseidon hash or KZG commitment to the model parameters used. Extracting data directly from the proof is essential for security, as transmitting the values separately could be manipulated. As noted above, because the VKA is vendor-supplied in the PoC, on-chain verification establishes validity relative to the vendor’s circuit; additional procedural controls (job specification, operator validation, and dispute/arbitration) are required to ensure the verified circuit matches the job’s intended evaluation semantics.

Given that ZKPs verify computational correctness but not subjective quality or intent, a dispute mechanism is implemented.

• Initiation: An OT Operator, believing the submitted solution is faulty despite a valid ZKP (e.g., the model doesn’t generalize, isn’t relevant, or fails other qualitative checks), can initiate a dispute before deadline 3.
• Arbitration: A small panel of Arbiters (three in the PoC implementation) is selected from a pool of registered addresses.
• Review & Voting: Selected Arbiters review the job details, the IT Vendor’s claim (proof and solution), and any evidence provided off-chain before submitting their binding vote on-chain. The current implementation does not enforce an on-chain voting timeout; settlement liveness therefore depends on arbiter participation (see Section 5.1.3).
• Resolution: A majority vote resolves the dispute, automatically triggering the release of escrowed funds to the winning party (either the OT Operator or the winning IT Vendor).

3.3. Core Operational Workflow

To illustrate the practical application of the proposed architecture in higher detail, this section details the step-by-step lifecycle of a collaborative task within the system, from initiation to completion or dispute resolution. The overall flow and potential state transitions are illustrated in the state diagram (Figure 3). The workflow is also visually depicted in the timeline in Figure 4. Everything is orchestrated by the on-chain systems (smart contracts), ensuring adherence to predefined rules, deadlines, and cryptographic verification procedures.

Job Creation: The process begins when an OT Operator defines a task. They specify parameters such as the baseline model details, the public test data, the baseline performance metric value against which improvements will be measured, the metric type (e.g., Mean squared error, MSE), the reward amount, and three crucial deadlines: deadline 1 for proof of improvement submissions, deadline 2 for the winner’s solution submission, and deadline 3 for dispute initiation. By creating a new job, the Operator simultaneously deposits the specified reward into an escrow contract controlled by the system. On-chain, this action instantiates a new Job entity, populating the $JobCore$, $JobDetails$, and $JobDeadlines$ tables with the provided parameters and setting the job status to $Open$ and $escrowLocked$ to true, signaling readiness for improvement submissions.

Proof of Improvement Submission and Verification: IT Vendors interested in a job retrieve the necessary details (model, data, requirements). Off-chain, they develop an improved model (e.g., using PyTorch) and integrate it with the evaluation logic specified for the ZKP variation being used (Variation 1, detailed in Section 3.4). Leveraging EZKL, the IT Vendor generates a zk-SNARK proof, client-side. This proof attests that their improved model achieves a better performance metric than the baseline on the public test data, crucially without revealing the model parameters themselves. This process also requires generating a unique VKA specific to the IT Vendor’s model circuit. Optionally, if the initial proof is too large for efficient on-chain verification, the IT Vendor can generate a compressed proof, though this increases client-side computation and memory requirements. Before deadline 1, the IT Vendor first deploys their unique VKA as a smart contract. They then submit their improvement (proof) by providing the deployed VKA address and the ZK proof itself (including public instances like the claimed new loss and the parameter hash). The Improvement System/contract immediately interacts with the deployed verifier wrapper contract, which uses the submitted VKA to verify the ZKP’s validity on-chain via the reusable Halo2 verifier. Upon successful verification, the wrapper extracts key outputs, including the actual loss achieved and the parameters hash (a commitment/hash to the model parameters used in the proof). The system checks if the proof indeed demonstrates an improvement over the baseline. If verification succeeds and improvement is confirmed, an $Improvements$ entity is created on-chain, storing the submission details (IT Vendor address, loss, VKA address, parameter hash, proof hash or IPFS hash pointing to the stored proof). The system also compares this new loss with the current best recorded loss for the job and updates the $JobCore.bestImprovementId$ if the new submission is superior.

Winner Selection: The improvement submission phase concludes after deadline 1. The winning submission is identified by referencing the final $JobCore.bestImprovementId$. If no valid proofs of improvement were submitted by deadline 1, the OT Operator can withdraw the escrowed funds, transitioning the status to $Expired$.

Solution Submission: The IT Vendor associated with the bestImprovementId is designated the winner. Before deadline 2, this winning IT Vendor must submit their solution identifier or, if needed, the full solution. In the PoC, this identifier is stored on-chain as a dynamic bytes field and is intended to be a compact handle (recommended 32 bytes in our evaluation) rather than the full model artifact. The on-chain workflow emits $keccak256\left(solution\right)$ upon submission to provide a fixed-size integrity reference even though the stored field is dynamic. The job status is then set to Closed. Should the winner fail to submit their solution by deadline 2, the job status transitions to Expired, enabling the OT Operator to reclaim the escrowed funds.

OT Operator Verification: Upon solution submission, the OT Operator retrieves the actual model artifact off-chain using the submitted solution identifier (e.g., a content address). Their primary verification step is to check if the submitted artifact corresponds to the cryptographic commitment (parameters hash) recorded during the proof verification phase. This ensures the IT Vendor submitted the same model parameters they used to generate the winning proof. If the hash matches, the Operator then performs any further qualitative checks necessary based on the job requirements. If the hash does not match, or if the solution is otherwise unsatisfactory, the Operator’s recourse is to initiate a dispute.

Reward Release/Completion: If the OT Operator is satisfied with the submitted solution (after performing the off-chain checks), they have the option to proactively release the escrowed funds to the winning IT Vendor before deadline 3. Alternatively, if deadline 3 passes and the job status is $Closed$ (meaning a solution was submitted) without any dispute being initiated, the system allows anyone (typically the winning IT Vendor) to trigger the final release of the escrowed funds to the IT Vendor. In both successful completion scenarios, the $JobCore.escrowLocked$ flag is set to false, the funds are transferred, and the job status transitions to $Completed$.

Dispute Resolution: If the OT Operator is dissatisfied with the submitted solution (e.g., parameter hash mismatch, failure to meet qualitative requirements despite a valid proof), they can initiate a dispute before deadline 3, optionally providing an IPFS hash pointing to evidence supporting their claim. This action transitions the job status to $Disputed$. A Disputes entity is created, and a predefined number of Arbiters (3 in the current implementation) are assigned from a registered pool of addresses. Assigned Arbiters review the job details, proof claim, submitted solution, and any provided evidence off-chain, and submit their individual votes on-chain. Section 5.1 discusses role-specific deterrence mechanisms including IT Vendor submission flooding, OT Operator dispute abuse, and arbiter liveness.

3.4. ZKP Variations

The choice of ZKP workflow for private contribution verification impacts the architecture, responsibilities, decentralization, and trust model of a trust-minimized collaborative system. We investigated three ZKP structures to understand these trade-offs and inform our PoC design. The selection of a particular variation shapes the resulting implementation; for instance, a business-oriented solution might favor efficiency and manageability via centralization (akin to Variation 0), whereas a goal of maximal decentralization points towards other designs (like Variation 1 or 2). The performance evaluation underpinning our final choice is presented subsequently in Section 4.2.

The first approach, Variation 0 (Aggregation & Argmin), can be seen in Figure 5. It envisions a more centralized or managed flow suitable for business-oriented deployments. In this model, IT Vendors would locally generate simple proofs of inference (${\pi }_i$), attesting only to the performance metric achieved by their model. These individual proofs would then be submitted to a dedicated off-chain aggregation server. This server carries out two additional ZKP steps. Initially, it combines the proofs of inference into an aggregate proof (${\Pi }_{agg}$). Subsequently, it produces an argmin proof (${\pi }_{argmin}$) of all submitted proof losses to effectively pinpoint the minimum loss among all submissions (index of smallest loss, i). While this potentially scales well by reducing the number of on-chain verifications to two (${\Pi }_{agg}$, ${\pi }_{argmin}$), it inherently introduces a centralized component (the aggregation server). This reliance raises concerns about trust, censorship resistance, complex coordination for the server’s operation, and the need for mechanisms to incentivize the aggregator.

The second approach, Variation 1 (Integrated Proof—Implemented), seen in Figure 6 offers a peer-to-peer solution where the primary computation occurs locally on users’ devices, with the blockchain orchestrating the collaboration. Here, each IT Vendor generates and submits a single, comprehensive ZKP (${\pi }_1$) covering the entire sequence (executing their model’s inference on test data, calculating the resulting loss (L) on the results (R), and comparing this loss against the job’s baseline loss (BL) to produce an improvement flag (True/False)). Note that while the final comparison could potentially be performed on-chain by having the proof only output the calculated loss, we chose to include the comparison within the ZKP circuit itself. This design decision encapsulates the core claim of “improvement achieved” atomically within the cryptographic proof, simplifies the data flow by aligning proof outputs directly with on-chain storage needs, and maintains a clear separation of concerns where the proof attests to the entire evaluation claim, rather than requiring the smart contract to perform part of the evaluation logic during submission verification. Optionally, a compression step can be included where ${\pi }_1$ is compressed to become ${\pi }_c$. This variation presents a simpler overall workflow and allows for direct, independent on-chain verification of each submission. Its main drawback is the reliance on the IT Vendor correctly including the specified loss calculation and comparison logic within their proven circuit; however, this risk is mitigated by the OT Operator’s final solution check and the availability of the dispute resolution mechanism.

The third approach, Variation 2 (Separated Proofs), seen in Figure 7, aims for finer verification granularity and stronger guarantees on the evaluation logic by splitting the process into distinct ZKP-proven steps. An IT Vendor would first generate a proof ${\pi }_1$, attesting to their model’s inference. Crucially, they would then generate a second non-zero-knowledge (public) proof ${\pi }_2$ using the predictions from Proof A along with public data (test set, baseline metric) to attest to the evaluation outcome.

The core design intent in Variation 2 is that Proof B (the evaluation proof ${\pi }_2$) is generated against a job-mandated evaluation circuit identity, i.e., a specific verification key (VK) or deployed Verification Key Artifact (VKA) chosen by the OT Operator at job creation. Improvement/proof submissions are only accepted if the evaluation proof verifies against this mandated VK/VKA, so the IT Vendor cannot choose the evaluation semantics. Operationally, this corresponds to an approved evaluation procedure/program identity for the procurement job.

Two operational options exist:

1.

Platform-standard evaluation VKA: A global, public evaluation circuit/VKA shared by the platform (e.g., a canonical loss definition and comparison logic).

2.

Job-specific evaluation VKA: The OT Operator deploys or registers a job-specific evaluation circuit/VKA at job creation (e.g., capturing a job-specific metric, baseline binding, and data-window commitment binding).

If IT Vendors are required to generate Proof B against the mandated VKA, the system gains cryptographic assurance that the evaluation logic (loss calculation and comparison) used matches the one specified by the Operator, shifting trust primarily to verifying the model used in Proof A. However, this enhanced guarantee comes at the cost of increased complexity (generating multiple proofs), increased verification overhead on-chain (verifying two proofs or requiring an additional aggregation proof step yielding proof ${\Pi }_{agg}$), and the need for the platform or OT Operator to manage the standardized evaluation circuit and VKA lifecycle.

We selected Variation 1 for the PoC implementation due to its balance of efficiency, simplicity and ability to create a completely peer-to-peer solution. The verification relies on the cryptographic soundness of the proof for the specific computation defined in the circuit, with the dispute mechanism acting as a fallback for issues outside the ZKP’s scope, like incorrect logic inclusion or subjective quality.

4. System Evaluation

In this section, we evaluate the implemented system to demonstrate its practical viability. We analyze its performance characteristics, focusing on the overhead associated with ZKP generation and the costs related to on-chain interactions. Security properties and trust assumptions are discussed separately in Section 5. The evaluation covers the measurable performance metrics of the ZKP workflows and the gas costs associated with the defined business logic scenarios executed on-chain.

4.1. Experimental Setup

All experiments were conducted locally on a consumer desktop machine equipped with an AMD Ryzen 7 3800XT 8-Core Processor and 32 GB of RAM, running Ubuntu Linux. The core components of the technology stack included: the EZKL framework (v20.2.4) for ZKP generation and verification based on the Halo2 proving system; the MUD framework for improved on-chain state management; PyTorch (v2.6.0) for ML model implementation; and Solidity (v0.8.24) for smart contract development. Contracts were compiled with the IR enabled (via_ir = true) and deployed to a local Anvil testnet using the Foundry/Forge development environment. All on-chain experiments were executed on a local Anvil development chain using the provided contract test harness. Recursive aggregation/compression steps incur multi-gigabyte proving artifacts and are evaluated as offline workstation/cloud-side operations rather than edge/PLC execution.

4.2. Experimental Model

For the Proof of Concept, we focused on time series forecasting using an ARIMA (AutoRegressive Integrated Moving Average) model implemented in PyTorch. This model class was selected for its suitability in demonstrating the ZKP workflow on consumer hardware due to its relatively simple and tunable complexity via parameters $(p,d,q)$. An $\mathrm{ARIMA}(p,d,q)$ model captures temporal dependencies by combining autoregression (AR), integration (differencing, I), and moving average (MA) components. Conceptually, after differencing the series d times to achieve stationarity ($Z_t={\Delta }^d{Y}_t$), the $\mathrm{ARMA}(p,q)$ prediction is:

$${\widehat{Z}}_t=\sum _{i=1}^p{\varphi }_i{Z}_{t-i}+\sum _{j=1}^q{\theta }_j{ϵ}_{t-j}$$

where ${\varphi }_i$ are AR parameters, ${\theta }_j$ are MA parameters, and ${ϵ}_t$ are past forecast errors. Forecasts ${\widehat{Z}}_t$ are then integrated back to the original scale ${\widehat{Y}}_t$. The models were trained on arbitrary industrial sensor telemetry (minute-resolution readings representative of vibration or pressure monitoring) against an arbitrary baseline loss of 0.1. This PoC evaluation therefore does not demonstrate private industrial dataset handling; rather, it evaluates the end-to-end proof and on-chain workflow on a time series with stochastic properties similar to industrial sensor data. In an OT deployment, the same workflow can be instantiated with operator-held datasets by committing to specific data windows (hash/commitment) and revealing only the agreed metric outputs. The key aspect for this work is that the ARIMA model, representable as a computational graph, serves as the input for the ZKP generation process. The choice of $(p,d,q)$ directly influences the model’s complexity, impacting the resulting ZKP circuit size and the setup/proving performance analyzed in Section 4.3.

4.3. Zero-Knowledge Proof Performance Analysis

Evaluating the performance of the ZKP components is critical for assessing the practical usability of the system, particularly regarding the computational burden on the IT Vendor (prover) and the cost incurred for on-chain verification (verifier). As discussed in Section 3.4, the ZKP workflow can be structured in different ways, each carrying distinct performance implications. We analyzed the three variations: Variation 0 (Server-side Aggregation & Argmin), Variation 1 (Client-side Integrated Proof with optional Compression, implemented in the PoC), and Variation 2 (Client-side Separated Proofs with Aggregation). The times in setup and proof generation (Section 4.3.1) along with the key and proof size (Section 4.3.2) analysis confirms that while ZKPs offer powerful verification capabilities, the resource demands (especially memory/storage for PKs) associated with recursive techniques like aggregation and compression currently limit their practicality for purely client-side execution, favoring simpler proof structures or hybrid architectures. Therefore, to enable a practical, client-side implementation for individual IT Vendors, Variation 1 (Integrated Proof) was chosen for the PoC. Its comparatively smaller resource requirements for the prover and its fully decentralized nature align well with the project’s goals.

4.3.1. Setup and Proving Times

The time required for the one-time setup (

Table 1. Zero-Knowledge Proof (ZKP) Setup Times (ST) and Proving Times (PT).

Variation	Proof	ST [s]	PT [s]	Executor
Variation 0	Initial (ARIMA 2,0,1)	2.6	2.9	IT Vendor
	Initial (ARIMA 1,0,1)	2.5	2.7	IT Vendor
	Aggregation (2 proofs)	225.6	1267.8	Agg. server
	Argmin (2 inputs)	4.5	6.4	Agg. server
Variation 1	Integrated (ARIMA 2,0,1)	2.9	3.3	IT Vendor
	Compression	38.3	73.4	Optional
Variation 2	Proof 1 (ARIMA 2,0,1 Plain)	2.7	2.8	IT Vendor
	Proof 2 (Loss Comp.)	2.1	3.0	IT Vendor
	Aggregation (2 proofs)	85.1	317.6	Optional

) (generating the proving and verification keys) and for generating each proof instance directly impacts the user experience, especially for the IT Vendor.

Setup: Key generation involves compiling the computational graph (ONNX model) into a circuit and generating the proving key (PK) and verifier key (VK). For the relatively simple ARIMA models used, the setup for individual proofs (Variations 1 and 2 initial proofs, Variation 0 initial proofs) was fast, taking approximately 2.5–3.0 s per model. However, setups involving aggregation (required for the final steps in Variations 0 and 2, and for optional compression in Variation 1) were significantly more time-consuming. The aggregation setup for Variation 0 (aggregating two initial proofs) took approximately 226 s, Variation 2’s aggregation setup took approximately 85 s, and Variation 1’s compression setup took approximately 38 s. The Argmin setup in Variation 0 was faster at approximately 4.5 s, reflecting its simpler circuit. As previously noted, these longer setup times are directly correlated with the large PK sizes, particularly the Proving Keys, as detailed in Section 4.3.2. The observed times suggest that memory size and speed are likely bottlenecks, especially given the 32 GB RAM limit of the test machine and the multi-gigabyte keys generated for complex steps. This highlights that server infrastructure with dedicated hardware would be necessary for such operations. Considering the IT vendors are expected to train models it would be assumed they have access to such resources, but it does limit the accessibility of these techniques for smaller vendors or edge devices without such capabilities.

Proving: Generating the actual proof, once the setup is complete, follows a similar pattern. Individual proofs took approximately 3 s. Variation 0’s server-side aggregation proof generation was the most demanding (approximately 1268 s), while Variation 2’s aggregation took approximately 318 s and Variation 1’s compression took approximately 73 s.

These results highlight the overhead associated with aggregation and compression techniques. While individual proof generation is relatively fast for the models tested, the aggregation steps shift the computational burden considerably, impacting either a required server (Variation 0) or the IT Vendor directly (Variations 1 and 2 if compression/aggregation is used). The longer setup and proving times for these steps, coupled with the key sizes discussed next, suggest that memory size and speed especially are bottlenecks on consumer hardware.

4.3.2. Proof and Key Sizes

The sizes of the generated proofs and cryptographic keys influence storage requirements, memory usage during setup and proving, and deployment feasibility.

The most striking observation from

Table 2. ZKP Key and Proof Sizes. (PK: Proving Key; VK: Verification Key).

Variation	Proof	PK Size	VK Size	Proof Size
Variation 0	Initial (ARIMA)	552 MB	257 KB	46 KB
	Aggregation (2 proofs)	33.0 GB	2.0 MB	24 KB
	Argmin (2 inputs)	1.3 GB	385 KB	28 KB
Variation 1	Integrated (No Aggr.)	624 MB	289 KB	28 KB
	Integrated (For Aggr.)	624 MB	289 KB	54 KB
	Compression	8.25 GB	513 KB	21 KB
Variation 2	Proof 1 (ARIMA Plain)	552 MB	257 KB	60 KB
	Proof 2 (Loss Comp.)	600 MB	289 KB	60 KB
	Aggregation (2 proofs)	16.5 GB	1.0 MB	34 KB

is the multi-gigabyte size of the Proving Keys (PKs) required for the aggregation and compression steps (8.25 GB to 33.0 GB), compared to the more manageable (though still substantial) 550–625 MB PKs for initial proofs. This presents a significant practical barrier for client-side execution of these recursive steps on typical consumer hardware, reinforcing the need for server infrastructure or substantial local resources. In contrast, Verification Keys (VKs, 250 KB—2.0 MB) and the final ZKP proofs (21–60 KB) remain compact, suitable for on-chain use. The compactness of the final proof is the primary motivation for the resource-intensive aggregation/compression steps. It is also worth noting the role of the Structured Reference String (SRS) in the process of generating the prover and verifier keys, a set of public parameters required by proving systems like Halo2, typically generated through a trusted setup or multi-party computation (e.g., the KZG Ceremony on Ethereum [29,30]). While EZKL can handle the download or generation of necessary SRS segments automatically, their size depends on the circuit complexity and can range from hundreds of megabytes to gigabytes. For instance, the SRS used in V1 compression is approximately 268 MB, and for V2 aggregation is around 512 MB. Although large, the SRS is needed only once for a given circuit size and is not user-specific like the PK.

Regarding circuit complexity, Variation 1 involves a single integrated circuit combining model inference and evaluation. Variation 2 separates these into two distinct circuits; while the loss computation logic itself might seem simpler than model inference, proving it over potentially large prediction and test data vectors still results in a ZKP circuit (and associated keys/proofs) of comparable size and complexity to the model inference circuit itself, as seen in Table 2.

These measurements also indicate the practical scalability boundary of the present approach. Prior work shows that proof generation time and proving-key size scale approximately linearly with the number of arithmetic constraints in the computational graph [22], but the mapping from model architecture to constraint count is not uniform. The ARIMA models evaluated here are therefore at the compact end of the spectrum; more complex architectures would require proportionally larger proving resources, with proving-key size remaining the dominant limiting factor in our measurements.

Table 2 further suggests that the largest artifacts in our experiments arise from aggregation and compression layers, not from the standalone ARIMA base models themselves. Even so, for a substantially larger model, the vendor-side base proof would already grow before any recursive overhead is added. In Variation 0, one may assume powerful hardware for the aggregation phase, but larger-model deployments would require similarly specialized hardware on the vendor side for proving as well. This reinforces our choice of Variation 1 for the PoC: server-side support for aggregation can help with recursive steps, yet it does not by itself remove the main proving bottleneck for substantially larger models.

4.4. On-Chain Workflow Cost Analysis

This subsection evaluates the gas consumption of the core smart contract functions implementing the defined business logic scenarios within our system, executed on a local Anvil testnet. Gas costs directly translate to transaction fees for users, making this analysis crucial for assessing the economic viability of the system on different blockchain networks. We analyze the gas costs across five key operational scenarios representing the primary paths through the system’s lifecycle:

• Optimal Path (Early Release): Job Creation → Deploy VKA → Proof Submission & Verification → Solution Submission → Verifies & Releases Funds Early
• Optimal Path (Deadline Release): Job Creation → Deploy VKA → Proof Submission → Solution Submission → IT Vendor Withdraws Funds
• Expired (No Improvements): Create Job → Operator withdraws funds
• Expired (No Solution): Job Creation → Deploy VKA → Proof Submission → Operator Withdraws Funds
• Dispute Path: Job Creation → Deploy VKA → Proof Submission → Solution Submission → Dispute initiation → Vote1 & Vote2 & Vote3.

Table 3. Measured On-Chain Gas Costs per Action (Local Testnet).

Action	Gas Used
Arbiter Registration	136,938; 154,038
Job Creation	289,043–308,979
VKA Deployment	1,591,798
Proof Submission	1,109,948–1,135,658
Solution Submission	157,588
Early Funds Release	143,982
IT Vendor Receives Funds	155,780
OT Operator Receives Funds	144,691; 150,556
Dispute Initiation	210,183
Arbiter Vote	108,829; 120,685
Arbiter Vote (Fund transfer)	228,823

summarizes the measured gas cost for each distinct on-chain action. While initial storage writes (SSTORE) and first-touch access patterns can incur higher gas costs, the table focuses on the subsequent, consistent costs, as these better represent the typical expenses users would encounter. Note that the “Operator funds Withdrawal” action shows two distinct costs, corresponding to withdrawals under Scenario 3 (if no improvements were submitted) and Scenario 4 (if a winning IT Vendor failed to submit a solution). Similarly, for “Arbiter Vote,” the minor variation observed between non-resolving votes is consistent with first-touch access patterns (e.g., the first interaction with a voting array incurs slightly higher overhead than subsequent interactions). The separate, higher cost listed as “Arbiter Vote (Fund transfer)” corresponds specifically to the final vote that resolves the dispute and triggers the fund transfer and associated state updates. Finally, both “VKA Deployment” and “Proof Submission” can vary with the specific ZKP circuit/VK used (i.e., the submitted VKA), because different circuits yield different on-chain verification workloads.

For “Solution Submission” in the PoC evaluation, the submitted on-chain payload is a compact 32-byte handle stored as a dynamic bytes field (rather than a full model artifact), so the reported gas reflects the intended identifier-based usage.

The on-chain gas cost analysis reveals several important characteristics of the system. A significant upfront cost for any potential contributor is the deployment of their VKA, requiring approximately 1.6 million gas. This initial VKA deployment cost is borne by the IT Vendor. In our measurements, VKA deployment varies modestly across circuits (e.g., 1,592,142 gas and 1,632,118 gas for two additional VKAs used in multi-bid tests), reflecting different circuit/VK metadata sizes.

Following this, the most significant recurring cost driver is the improvement submission action, consuming approximately 1.11–1.14 million gas due to the inclusion of cryptographic ZKP verification on-chain. This cost varies both with the circuit being verified (different submitted VKAs) and with state-update effects (e.g., whether a submission becomes the new best improvement). Job creation is the next most costly step for the OT Operator (approximately 290 k–310 k gas), involving multiple state writes across MUD tables and the escrow transfer. Most other individual actions remain in the low hundreds of thousands of gas, with some variation depending on whether the call triggers additional state transitions (e.g., the final arbiter vote that releases funds).

Comparing the end-to-end scenarios (visualized in Figure 8), the “Optimal Path” workflows (Scenarios 1 and 2) require approximately 3.31–3.34 million gas in total (including a one-time VKA deployment by the participating IT Vendor). The IT Vendor bears the majority of this cost (approximately 2.71–2.88 million gas), largely due to the combined expense of VKA deployment and the subsequent proof submission.

The “Expired” scenarios where no solution is ultimately paid for (Scenarios 3 and 4) range from approximately 0.45 million gas (if no proofs/improvements are submitted, entirely borne by the Operator) to approximately 3.17 million gas (if a proof including VKA deployment is submitted but no solution follows). Engaging in the dispute process (Scenario 5) adds a noticeable overhead, bringing the total cost to approximately 3.85 million gas in our example, with the IT Vendor still carrying the largest share due to the initial VKA and submission costs, followed by the Operator and Arbiters.

The economic practicality is inherently tied to blockchain gas costs. Deploying on Layer 2 or Layer 3 solutions transforms the cost equation, making the system highly feasible. The following cost figures are illustrative and depend on deployment and market assumptions, including (i) chain/fee model (Layer 2 (L2) vs Layer 3 (L3), execution gas plus any data-availability posting fees), (ii) gas price, (iii) ETH/USD exchange rate, and (iv) calldata/data-availability pricing at measurement time. Consider the VKA deployment (approximately 1.6 M gas) and proof submission (approximately 1.1 M gas), the most gas-intensive operations for the IT Vendor. On an established Layer 2 like Optimism, where average gas prices historically trend well below 0.1 Gwei, the VKA deployment might cost around $0.32 and the submission $0.23 (assuming 0.1 Gwei and 1 ETH = $2000, and using execution gas as a first-order approximation). On emerging infrastructure aiming for even lower fees (e.g., 0.05 Gwei), these could drop to roughly $0.16 and $0.11 respectively. Even using a more conservative general L2 gas price estimate of 1 Gwei, the costs remain manageable at approximately $3.18 and $2.27. These figures represent a reduction compared to potential Ethereum Layer 1 (L1) costs. Therefore, deploying this system on established L2 rollups or within a dedicated Layer 3 environment renders it economically practical for a wide array of competitive ML procurement tasks, grounding its potential for real-world application.

4.5. Real-Time Constraints in CPS Deployment

A critical consideration for deploying this framework in Industrial Cyber-Physical Systems is the reconciliation of ZKP generation times with the stringent real-time requirements of control loops. As demonstrated in Section 4.3.1, proof generation for individual models takes approximately 3 s, while more complex operations involving aggregation or compression can require several minutes. These timescales are incompatible with typical industrial control cycles, which often demand response times under 100 ms for safety-critical operations. In many industrial settings, PLC scan cycles are typically on the order of 1–50 ms, and some safety functions governed by standards such as IEC 61511 or IEC 62061 can require even tighter deterministic response bounds [31,32]. Accordingly, the blockchain/ZKP layer is never placed in these latency-critical paths.

However, our framework is specifically designed to address this challenge through a temporal separation of verification and execution phases. The ZKP generation and on-chain verification occur entirely offline during the model procurement and upgrade approval phase, before any deployment to physical assets. This process flow ensures that:

• Pre-Deployment Verification: IT Vendors generate proofs client-side during the procurement phase, demonstrating their model’s performance improvement. The smart contract verifies these proofs and selects the winning model, all before any code touches the physical system.
• Zero Runtime Overhead: Once a model is cryptographically verified and deployed to the edge controller (PLC, RTU, or embedded system), it operates as a standard inference model with no cryptographic overhead. The verified model executes in the real-time control loop with the same performance characteristics as any conventional model.
• Separation of Concerns: The verification layer (blockchain + ZKP) and the execution layer (edge device) are architecturally decoupled. The blockchain acts as a trust anchor and procurement platform, while the edge device focuses solely on real-time performance.

This architectural pattern aligns with established practices in safety-critical systems [33,34], where software certification and validation occur offline (e.g., DO-178C in avionics and IEC 61508 in industrial automation [35,36]), while runtime execution must meet strict deterministic timing guarantees. It is also consistent with IEC 62443-style network segmentation and separation of duties [26,27], where validation and procurement services may depend on IT-side infrastructure, but the OT control zone must continue operating independently of that infrastructure. We use these standards as an analogy for offline-vs-runtime separation (not as a claim of compliance); our contribution is a cryptographic verification gate during the offline validation phase.

For industrial operators concerned about model drift or malicious updates in deployed systems, the workflow can be extended with periodic re-verification during scheduled maintenance windows (e.g., generating updated proofs over newly agreed data windows and baselines without interrupting real-time operation). This periodic re-verification loop is not implemented in this paper and would require explicit operational policies (data window commitments, trigger conditions, and acceptance rules) to integrate safely into an OT change-management process.

5. Security Discussion

The proposed platform is designed for trust-minimized collaboration by minimizing reliance on central authorities and maximizing verifiable interactions through cryptographic methods and blockchain-based orchestration. Key security properties are achieved by using ZKPs and smart contract enforcement, but certain limitations and trust assumptions remain.

The primary security objective is to safeguard the IT Vendor’s intellectual property throughout the collaboration. By using ZKPs, IT Vendors can cryptographically prove that their enhanced models meet specific performance criteria (e.g., achieving a lower loss score than a baseline) without prematurely disclosing the valuable underlying model parameters. The integrity of this claim is further strengthened by including a parameter hash within the proof’s public outputs. This hash serves as a cryptographic commitment to the specific model version used to generate the proof, stored immutably on-chain within the improvement submission data. Due to gas costs associated with on-chain verification, in our implementation, this hash is verified off-chain by the OT Operator upon solution submission.

On-chain ZKP verification confirms the computational correctness of the IT Vendor’s submitted proof against their provided VKA. This step effectively filters out invalid proofs or computationally unsound claims before they are even considered. Procedural fairness is enforced by the system’s smart contracts, which manage the job lifecycle.

Despite these mechanisms, the system is not without limitations. A crucial nuance, particularly with the implemented Variation 1 (Integrated Proof) workflow, is the scope of the ZKP guarantee. While the ZKP cryptographically proves the computational correctness of the specific circuit defined by the IT Vendor (e.g., confirming that the inference, loss calculation and comparison operations were executed as defined in their circuit), it does not inherently guarantee that the logic implemented semantically matches the OT Operator’s intended evaluation criteria. A malicious IT Vendor could potentially construct a circuit with manipulated evaluation logic that still yields a valid proof. This risk is primarily mitigated by the combination of the on-chain parameter Poseidon hash included in the proofs, which forces the winner to submit the actual parameters used, and the essential off-chain verification step where the OT Operator must independently run the submitted model with the correct, specified evaluation logic before finalizing the reward release.

Variation 2 (Separated Proofs) can make this semantic binding explicit by requiring the evaluation proof to verify against a job-mandated evaluation VK/VKA specified by the OT Operator at job creation (either a platform-standard evaluation VKA or a job-specific evaluation VKA registered by the Operator). This turns the evaluation semantics into an approved evaluation procedure/program identity for the procurement job: the IT Vendor remains free to choose and keep private their model parameters, but cannot substitute the loss definition, baseline binding, or other evaluation rules without failing on-chain verification of the mandated evaluation proof.

5.1. Economic Deterrence and Game-Theoretic Security

Beyond cryptographic validity checks and procedural safeguards, the workflow imposes economic friction on participants that can deter low-effort spam and raise the cost of denial-of-service (DoS)-style abuse. This friction is not a proof of DoS resistance, but it does provide a practical filtering layer in many deployments.

First, the system introduces unavoidable on-chain costs: deploying a VKA, submitting an improvement, and paying for proof verification all consume gas. Second, the workflow includes off-chain costs: generating ZK proofs requires non-trivial CPU/RAM (and, depending on the proving setup, potentially GPU) resources and time. Third, the system exhibits a self-selection effect: because the best recorded submission state (e.g., lowest verified loss) is public, rational IT Vendors can choose not to incur proving and transaction costs when they observe they are unlikely to win.

In a simple rational-adversary framing, repeated malicious or spam submissions become unattractive when

$$\mathrm{Cost}\left(\mathrm{Attack}\right)>\mathbb{E}\left[\mathrm{Reward}\right],$$

where $\mathrm{Cost}\left(\mathrm{Attack}\right)$ includes gas fees plus the off-chain proving compute budget. Baseline gas and proving costs already impose friction, but for high-value jobs these alone may be insufficient to deter a well-funded adversary. Stronger deterrence requires additional stake or fee exposure, with the choice of instrument depending on the abuse channel: a refundable bid bond is best suited to objectively attributable protocol violations, whereas a non-refundable participation fee is the stronger tool against pure submission flooding. Section 5.1.1 formalizes this intuition into a multi-term expected-utility inequality.

The remainder of this section distinguishes three role-specific abuse channels that require partially different controls: (i) IT Vendor submission flooding and manipulation during bidding, (ii) OT Operator dispute abuse after winner selection, and (iii) arbiter non-participation during dispute resolution. The first channel primarily concerns entry conditions, spam resistance, and bidder screening; the second concerns delay tactics and procedural misuse by the buyer; and the third concerns settlement liveness once arbitration has started. The following subsubsections discuss these channels in turn and explain where bonds, fees, staking, and reputation are most appropriate.

5.1.1. IT Vendor Submission Flooding and Manipulation

Not every losing or low-performing submission is misconduct. A valid proof that simply loses on performance should not be slashed automatically, because compliant but uncompetitive participation is part of a competitive procurement market. This matters for IT Vendor abuse because flooding may consist of many valid-but-uncompetitive submissions, leaderboard gaming, or repeated attempts to impose proving and verification overhead on the platform rather than a single objectively invalid proof.

The mechanism design goal is to ensure that the attacker’s expected utility is zero or negative, so that rational adversaries are not incentivized to flood the system. Formally, the attacker’s expected utility can be expressed as

$$\mathbb{E}\left[U_{\mathrm{attack}}\right]=\mathbb{E}\left[G_{\mathrm{attack}}\right]-n\left(C_{\mathrm{gas}}+C_{\mathrm{prove}}+F_{\mathrm{entry}}+C_{\mathrm{lock}}(B,T)\right)-\mathbb{E}\left[S_{\mathrm{slash}}\right],$$

where $\mathbb{E}[·]$ denotes the expected value, $U_{\mathrm{attack}}$ is the attacker’s utility, $G_{\mathrm{attack}}$ is the attacker’s perceived gain from carrying out the flooding attack, n is the number of attack submissions, $C_{\mathrm{gas}}$ is the on-chain transaction cost per submission, $C_{\mathrm{prove}}$ is the off-chain proof-generation cost per submission, $F_{\mathrm{entry}}$ is any non-refundable participation fee, $C_{\mathrm{lock}}(B,T)$ is the opportunity cost of locking a refundable bond of size B for duration T, and $S_{\mathrm{slash}}$ is the slashing penalty. The expected-value operators reflect the fact that the attacker decides under uncertainty: the gain $G_{\mathrm{attack}}$ is uncertain because the attacker cannot know in advance whether the flooding will actually succeed in suppressing competitors or influencing the procurement outcome, and the slashing penalty $S_{\mathrm{slash}}$ depends on the probability of detection and adverse arbiter ruling. In contrast, the per-submission cost terms ($C_{\mathrm{gas}}$, $C_{\mathrm{prove}}$, $F_{\mathrm{entry}}$, $C_{\mathrm{lock}}$) are treated as approximately known at decision time, which is why they appear without $\mathbb{E}$. The design objective is $\mathbb{E}\left[U_{\mathrm{attack}}\right]\le 0$: the aggregate cost terms on the right-hand side must outweigh the attacker’s expected gain, so that a rational risk-neutral adversary is not incentivized to attack.

The gain term $\mathbb{E}\left[G_{\mathrm{attack}}\right]$ is inherently subjective and context-dependent. In a competitive procurement setting it could represent, for example, the expected profit from suppressing legitimate competitors (e.g., crowding out their submissions via gas-price competition), the strategic value of manipulating leaderboard rankings to discourage future bidders, or the benefit of forcing the OT Operator into a worse procurement outcome. The mechanism designer cannot directly control $G_{\mathrm{attack}}$; therefore, deterrence must be achieved by tuning the cost-side parameters (fees, bond sizes, slashing rules, and submission caps) to ensure the inequality holds for a realistic range of adversary valuations.

Refundable bonds impose a liquidity constraint that complements these per-submission costs. If each submission requires a refundable bond B that remains locked until the job closes, then an attacker attempting n simultaneous submissions must immobilize roughly $nB$ capital for the lock period. For high-value jobs this can be substantial, so refundable bonds raise the cost of flooding through capital lock-up even when the principal is eventually returned. That said, this is only a partial deterrent; a sufficiently well-capitalized attacker may still find such a strategy worthwhile unless there are additional non-refundable costs or penalties. Under a purely refundable-bond design, $F_{\mathrm{entry}}\approx 0$ and $\mathbb{E}\left[S_{\mathrm{slash}}\right]\approx 0$ for compliant losing bids, so deterrence depends mainly on gas costs, proving costs, and capital lock-up. A production deployment should therefore likely combine a compliance bond with a small non-refundable per-submission fee, escalating fee schedule, minimum-improvement threshold, submission cap, or commit-reveal rule to reduce spam, late sniping, and gas-war dynamics. These parameters must be carefully calibrated: if fees or bond requirements are set too high, they risk deterring honest, smaller IT Vendors from participating at all, thereby reducing competition and undermining the procurement market the platform is designed to enable. Section 5.1.4 discusses this accessibility–deterrence trade-off further.

5.1.2. OT Operator Dispute Abuse

The same logic applies to the OT Operator role. An Operator could abuse the workflow by repeatedly initiating disputes to delay payout, force additional review costs on the winning IT Vendor, or create bargaining leverage after the proof phase has already succeeded. However, unlike the IT Vendor role, the OT Operator already has escrowed funds locked in the protocol, so there is already some skin in the game before the dispute starts. For that reason, a separate dispute bond should be viewed as an optional hardening mechanism rather than an automatic requirement for every deployment.

OT Operator penalties therefore require more care than missed-deadline penalties. Failing to submit required evidence by a specified deadline is objectively attributable and therefore a plausible slashing condition. By contrast, punishing a supposedly frivolous dispute is harder because that judgment depends on arbiter honesty and incentive alignment rather than purely mechanical on-chain evidence. Consequently, if dispute bonds are used, they should primarily target provable process violations and delay abuse, not discourage legitimate good-faith challenges to semantically incorrect or operationally unsuitable submissions.

5.1.3. Arbiter Non-Participation, Deadline 4, and Bounded Replacement

Arbiter non-participation creates a distinct attack surface because it can stall settlement even when the proof and escrow logic are otherwise functioning correctly. A concrete production design would define an explicit voting deadline, i.e., a potential deadline 4, as the dispute-initiation timestamp plus a configurable voting window such as 72 h. If an assigned arbiter fails to vote before deadline 4, that arbiter could be slashed and replaced by the next eligible arbiter from the pool.

This replacement process should be bounded. Without a hard cap, repeated non-participation could create an infinite cascade of replacement rounds. A more defensible design is to permit a fixed maximum number of replacement rounds, for example two rounds, each using the same voting window. If all rounds are exhausted without resolution, the protocol should fall back to a default outcome specified ex ante, such as returning funds to the disputer, refunding by rule, or applying another conservative settlement path. The precise fallback is a mechanism-design choice, but the bounded-round structure is what prevents indefinite escrow lockup.

The slashing rule must also be economically meaningful. If the expected slash amount is smaller than the effort cost of participating, rational arbiters may still choose inactivity. Accordingly, the arbiter stake posted at registration should be large enough that honest, timely voting remains the dominant strategy once voting fees and slash exposure are considered. This follows a standard decentralized-arbitration pattern and is consistent with prior art such as Kleros [37], which treats staking, deadlines, and repeated rounds as core liveness tools rather than optional embellishments.

The arbiter mechanisms described above (deadline 4, bounded replacement rounds, and role-specific slashing rules) are not implemented in this paper; they constitute a design-level specification for how a production version could harden settlement liveness.

5.1.4. Cross-Cutting Trade-Offs and Scope

The preceding subsubsections address each abuse channel primarily through economic friction: bonds, fees, staking, and deadlines. But it is clear a second cross-cutting instrument, reputation, applies to all three roles. It operates at a different layer, as a pre-transaction coordination mechanism that filters participants before a contract is formed, based on observable workflow outcomes, rather than as a per-transaction deterrent.

Reputation applies symmetrically to all three roles. For IT Vendors, role-specific reputation scores derived from outcomes such as timely submission and successful artifact delivery could serve as admission filters or ranking signals, enabling OT Operators or platform policies to screen bidders before high-value jobs are opened. For OT Operators, recording dispute outcomes on-chain means that operators who repeatedly open weak or unsuccessful disputes become less attractive counterparties, causing strong IT Vendors to avoid their jobs or requiring stricter participation thresholds; this is a lower-friction first-line control compared to adding new collateral requirements to every dispute. For arbiters, a production system could filter by minimum stake, recent availability, and a reputation threshold derived from observable behavior such as timely voting, agreement with finalized outcomes, and participation history, then randomly sample from that eligible subset. This preserves unpredictability while making repeat non-participation less likely to be rewarded with future assignments, creating a market-level penalty: an arbiter who repeatedly misses deadlines may retain system access in principle but will receive less work in practice.

However, reputation introduces its own design tensions. Scoring can improve participant screening but can also entrench incumbents and penalize newcomers unless identity persistence, rating update rules, and recovery from early negative events are designed carefully. Reputation systems also require persistent identity assumptions and are vulnerable to cold-start and Sybil problems. Accordingly, reputation should be treated as a complement to staking, deadlines, and economic friction, not as a complete substitute for them.

On the fee and bond side, large fixed amounts would exclude smaller but legitimate vendors and reduce competition, whereas percentage-based or tiered structures preserve accessibility for lower-value jobs while still scaling deterrence for high-value procurements.

None of these mechanisms (bid bonds, dispute bonds, arbiter staking, entry-fee rules, or on-chain reputation) are implemented in this paper, as doing so would require dedicated mechanism-design research, formal game-theoretic analysis, smart-contract engineering, and empirical simulation across the parameter space that together constitute a research effort of their own. Furthermore, the mechanisms described in this section are not specific to ML procurement; they apply broadly to any on-chain collaboration platform with competitive bidding, arbiter-based dispute resolution, and escrow. That generality makes them a natural contribution for a dedicated follow-on study rather than an incremental addition to this paper.

5.2. Safety-Critical Validation for Industrial CPS

In Industrial Cyber-Physical Systems, deploying unverified or malicious models can have consequences ranging from undetected equipment failures to excessive false alarms that erode operator trust in safety systems [38].

Our framework addresses these safety concerns through a pre-deployment verification gate that fundamentally differs from traditional Over-The-Air (OTA) update mechanisms. As discussed in Section 2, conventional OTA systems verify authenticity (origin via digital signatures) but do not provide cryptographic evidence about pre-deployment evaluation results [11,39]. An attacker who compromises a vendor’s signing key, or a vendor who inadvertently introduces a regression bug, can still deploy code that passes cryptographic authentication checks despite failing to meet the Operator’s pre-deployment expectations.

In contrast, our ZKP-based verification cryptographically proves that:

• The proposed model achieves specific, measurable performance improvements on representative test data (e.g., “anomaly detection recall > 95%” or “MSE < 0.05”).
• The reported metric value is the result of correctly executing the agreed evaluation circuit (e.g., inference + loss computation + comparison) associated with the verification key.
• The model revealed for deployment is exactly the model that was evaluated in the proof, enforced through the parameter commitment hash verified by the Operator before deployment.

This approach provides a verifiable pre-deployment evaluation record for industrial ML deployment. Before any model touches a physical actuator or influences a control decision, it must first prove its evaluation result in a zero-knowledge sandbox environment using historical or synthetic operational data. The smart contract acts as an immutable audit trail, recording which models were proposed, what performance they claimed, and which model was ultimately selected for deployment. This trail is valuable for post-incident forensics and regulatory compliance (e.g., demonstrating due diligence in safety-critical incidents).

Furthermore, by decoupling the verification phase (which occurs on-chain with full transparency) from the deployment phase (which occurs on isolated OT networks), the framework enables industrial operators to maintain strict network segmentation, a cornerstone of IEC 62443 industrial cybersecurity standards [26,27]. The operator can download the verified model artifact via an operator-controlled channel such as a unidirectional data diode or air-gapped transfer, ensuring that even a compromised blockchain network cannot directly inject malicious code into the OT environment. The on-chain record provides an auditable authorization trail; implementing on-device (PLC-side) proof verification is out of scope for this paper and would typically be handled by an OT-side engineering workstation or gateway before installation.

The dispute resolution mechanism serves as a critical backstop for addressing such semantic discrepancies, subjective quality disagreements, or other issues falling outside the ZKP’s direct scope. Importantly, the ZKPs actively assist this process. By providing objective cryptographically verified evidence, the proofs narrow the potential scope of disputes. Arbiters are not required to re-evaluate the raw computation; instead, they can focus their assessment on the semantic alignment of the IT Vendor’s work, the consistency between the submitted solution and the on-chain commitment, and any other qualitative job requirements. However, this mechanism reintroduces an element of trust in the selected Arbiters, and robust arbiter incentive and penalty mechanisms are needed to ensure liveness (see Section 5.1.3).

Hardening arbiter liveness through deadline 4, staking, and bounded replacement rounds is addressed in Section 5.1.3 and Section 7. Similarly, the system relies on the OT Operator providing fair and representative test data, as maliciously crafted data could unfairly skew results.

Taken together, the ZKP-based verification gate, the on-chain audit trail, the network-segmented deployment path, and the dispute resolution backstop form a layered defense that addresses both the cryptographic and the procedural dimensions of safe model procurement for Industrial CPS. The economic deterrence mechanisms discussed in Section 5.1 provide an additional friction layer against spam and low-effort abuse, while the remaining trust assumptions (arbiter honesty, data representativeness, and semantic alignment) delineate the boundaries within which the framework’s guarantees hold.

6. Conclusions

This paper presented a procurement-time verification framework for Industrial CPS in which third-party vendors can cryptographically attest that a candidate ML model improves upon a baseline on agreed evaluation data without revealing proprietary model parameters. By combining Zero-Knowledge Proofs with smart-contract orchestration (escrow, submission deadlines, automated winner selection, and dispute handling), the approach reduces reliance on NDAs and manual audits during competitive model procurement while keeping the verification workflow fully offline and out of the real-time OT control path.

In critical infrastructure and industrial cyber-physical systems, this workflow acts as an additional procurement-time trust layer between OT Operators and external IT Vendors by making model evaluation claims auditable and cryptographically verifiable before deployment. This aligns with industrial security engineering principles in ISA-99/IEC 62443 [26,27], where changes to OT-relevant software are governed by controlled, reviewable processes and strong separation between validation activities and operational execution.

A key part of our research involved analyzing different ZKP workflow variations to balance decentralization, efficiency, and security (Section 3.4). We compared strategies including server-side aggregation (Variation 0), client-side integrated proofs (Variation 1), and separated proofs for inference and evaluation (Variation 2). Our performance evaluation assessed setup/proving times and key/proof sizes for these variations using an ARIMA model forecasting task. The analysis confirmed that while recursive techniques like aggregation and compression offer proof size benefits, they incur substantial resource costs, particularly multi-gigabyte Proving Key (PK) sizes (up to 33 GB observed) and long setup/proving times (minutes to approximately 20 min observed), making them challenging for purely client-side execution on typical hardware.

Based on these findings, we selected and implemented Variation 1 (Integrated Proof), generating a single, integrated ZKP client-side. This approach proved feasible for individual improvements on consumer hardware (approximately 3 s proving time, 624 MB PK) and enabled a fully peer-to-peer workflow, successfully demonstrating job creation, secure ZKP submission and on-chain verification, automated winner selection, solution handling via commitments, and arbiter-based dispute resolution. Furthermore, our on-chain gas cost analysis showed the system’s economic viability on Layer 2/3 solutions (e.g., sub-dollar costs for key operations like VKA deployment and proof submission under typical Ethereum based Layer 2 scaling solutions assumptions), grounding its practical potential. This work provides a validated foundational step and demonstrates a novel application for secure, incentivized, and verifiable competitive procurement in ML and potentially other complex decentralized software development tasks.

7. Future Work

Building on the procurement-time verification framework and the presented proof-of-concept, future work focuses on production hardening for Industrial CPS deployments and on extending the approach to broader verifiable procurement settings. Key research directions include:

• Expanding Platform Use: The system currently targets ML models, but its foundation could support wider software development tasks. OT Operators could define jobs, allowing IT Vendors (and potentially automated agents) to tackle the problem, shifting payment towards the final solution instead of time or resources. This differs from simply using autonomous agents to build products directly. Exploring Multi-Party Computation (MPC) could also enable more complex scenarios with multiple participants working together securely.
• Agentic Use Cases: Future work should explore trust-minimized agent participation in procurement workflows, where autonomous agents can discover jobs, submit cryptographically verified bids, and receive automated settlement on-chain. This is an application direction enabled by the framework’s properties (not an added formal guarantee), and the same trust assumptions and temporal boundaries apply as for human participants.
• Improving Dispute Resolution: As noted in Section 5.1, a production-ready dispute system should introduce an explicit voting timeout (deadline 4), arbiter staking, bounded replacement rounds, and a predefined fallback outcome if all replacement rounds are exhausted. Future work could entail calibration and validation of these mechanisms. This includes studying suitable voting-window lengths, slash fractions, replacement-round caps, fallback policies, and whether arbiter selection should combine randomness with reputation, and stake-based eligibility filters. Exploring Large language model (LLM)-assisted arbiters, potentially in secure execution environments, and allowing an OT Operator to select the second-best verified solution after a successful dispute might also be valuable extensions.
• Refining Economics and Fairness: Clear rules for arbiter compensation are necessary, perhaps funded by small reward deductions or integrated with systems like Kleros. Furthermore, the “winner-takes-all” model might create fairness issues or strategic bidding (“gas wars”); alternative reward structures (e.g., paying top contributors) or reputation systems could encourage wider participation. Another open problem is to calibrate role-specific deterrence across all three abuse channels identified in Section 5.1: IT Vendor submission flooding, OT Operator dispute abuse, and arbiter non-participation. Future work should therefore treat economic hardening as a formal mechanism-design problem for all protocol roles, not only IT Vendors, by simulating attacker and honest-participant behavior across job values, proving costs, gas prices, capital lock-up costs, dispute probabilities, voting-window lengths, chain congestion, and reputation-update rules. This is needed to estimate equilibrium participation, attack profitability, and appropriate ranges for bid-bond percentages, dispute-bond sizes, arbiter-stake levels, slash fractions, entry-fee schedules, and reputation thresholds.