Verifiable Differential Privacy Partial Disclosure for IoT with Stateless k-Use Tokens

TL;DR

This paper introduces a privacy-preserving method for IoT systems that limits data disclosure while ensuring compliance and performance.

Contribution

A novel stateless k-use token mechanism with verifiable differential privacy for IoT partial disclosure.

Findings

The stateless k-use mechanism improves throughput by 25–37% compared to server-state baselines.

Re-identification accuracy remains at 0.50–0.52, indicating strong resistance to splicing attacks.

The system demonstrates low-energy feasibility and audit-friendliness in IoT applications.

Abstract

Internet of Things (IoT) applications often require only minimal necessary information—such as threshold judgments, binning, or prefixes—yet they must control privacy leakage arising from multi-round and cross-entity access without exposing raw values. Existing solutions, however, frequently rely on ciphertext structures and server-side states, making it difficult to define a leakage upper bound for restricted answers in the sense of Differential Privacy (DP), or they lack unified information budgeting and k-use control. To address these challenges, this paper proposes a verifiable differential privacy partial disclosure scheme for IoT. We employ DP accounting to uniformly constrain the leakage of three types of operators: threshold, binning, and prefix. Furthermore, we design stateless k-use tokens based on Verifiable Random Functions (VRFs) and chained receipts to generate publicly verifiable compliance evidence for each response. We implemented an end-edge-cloud prototype system and evaluated its performance on two use cases: smart meter threshold alarms and industrial sensor out-of-bound detection. Experimental results demonstrate that compared with a baseline relying on server-state counting for k-use control, our stateless k-use mechanism improves throughput by approximately 25–37% under concurrency scales of 1, 8, and 16, and reduces p95 latency by an average of 15%. Meanwhile, in multi-party splicing attack experiments, the re-identification accuracy remains stable in the 0.50–0.52 range, approximating random guessing. These results validate that the proposed scheme possesses low-energy engineering feasibility and audit-friendliness while effectively suppressing splicing risks.

Figures

Full text

1. Introduction

IoT systems are shifting from the centralized processing of uploaded raw data to cloud-edge collaborative computing [1], where terminals and edge nodes are required to provide only the minimal necessary information. Many applications do not require the raw values themselves but rather focus on whether a value crosses a specific threshold, falls into a discrete interval (binning), or matches a prefix rule. The rise of machine learning applications in IoT [2] has further increased the demand for privacy-preserving techniques. While differential privacy has been successfully applied to deep learning [3], adapting these techniques to resource-constrained IoT environments with verifiability requirements remains an open challenge.

To clarify the privacy protection scope discussed in this paper, we first briefly review related definitions. Differential Privacy (DP) [4] provides a rigorous mathematical frame-work that, by injecting an appropriate amount of noise into query results, probabilistically ensures that the presence or absence of a single record does not significantly alter the output distribution, thereby concealing individual characteristics. Local Differential Privacy (LDP) [5,6] further pushes this protection boundary to the data source, requiring that data be perturbed before leaving the device. This approach eliminates reliance on trusted third-party servers, ensuring that even in environments where servers are untrusted, attackers cannot infer users’ sensitive information from collected data.

However, without unified privacy accounting and verifiable evidence, such restricted responses—once spliced across different authorizations and multiple rounds—may still leak sensitive details. Furthermore, approaches relying on server-side persistent states or Trusted Execution Environments (TEEs) struggle to maintain long-term audit reproducibility in environments characterized by heterogeneous devices and unstable networks.

Several technical approaches focus on ciphertext-domain evaluation and access pattern control, yet critical limitations persist. In the domain of Order-Revealing/Preserving Encryption (ORE/OPE) and Property-Preserving Hashing (PPH), representative works [7,8,9,10] support comparison operations but suffer from cumulative order and boundary leakage under multi-round access. Similarly, Structured Searchable Encryption (SSE) schemes [11] consistently fail to conceal access patterns and result volumes. Research on leakage-abuse attacks [12,13] demonstrates that attackers can exploit these weaknesses via statistical approximation, highlighting the lack of “auditable and constrainable” leakage characterization in existing mechanisms.

Furthermore, a unified solution for Differential Privacy (DP) and access control remains elusive. Although Differential Privacy (DP) and Local Differential Privacy (LDP) mechanisms [5,6,14] are robust for statistical analysis, they struggle to represent discrete restricted operators (e.g., binning) and lack a unified budget model for multi-round auditability. Regarding access frequency limiting, existing schemes [15,16] typically rely on server-side persistent states or trusted hardware, making it difficult to maintain consistency across distributed edge and multi-cloud environments.

Finally, in the realm of verifiable computing [17], although systems like Pinocchio, PLONK (Permutations over Lagrange bases for Oecumenical Noninteractive arguments of Knowledge), and Verifiable Random Functions (VRFs) [18,19,20] provide mature tools for verifying single operators and randomness, they are insufficient for complex state-dependent scenarios. Existing works generally fail to provide a unified verification statement covering “mechanism consistency, budget deduction, and k-use limits,” effectively preventing the replayable auditing of multi-round restricted invocations.

Consequently, current research—both domestic and international—has not yet formed comprehensive solutions in the following three aspects: (1) controllable leakage boundaries under multiple authorizations and cross-entity splicing; (2) a unified information budget model for restricted operators such as ranges, binning, and prefixes; (3) k-use limits and verifiable evidence chains that function without server-side persistent states. These challenges constitute the primary motivation for the method proposed in this paper.

The main contributions of this paper are summarized as follows:

• We propose a verifiable differential privacy partial disclosure scheme for IoT data. Unlike a simple loose coupling of differential privacy accounting and API rate limiting, we atomically bind privacy budget consumption and k-use access control within a zero-knowledge proof relation. This design ensures that query proof generation must simultaneously satisfy dual constraints, thereby eliminating reliance on trusted server states, preventing separated attacks that bypass policies in a single dimension, and achieving full-process auditability.
• We present a unified system model and verification relation that encodes mechanism consistency and budget limits, enabling any party to independently audit unauthorized access or budget overdrafts via a publicly verifiable evidence path without accessing raw data.
• We implement a full-lifecycle prototype and demonstrate, through extensive performance evaluations and splicing attack simulations, that the system maintains acceptable constant-level engineering overheads and auditable risk bounds under practical parameters.

The remainder of this paper is organized as follows: Section 2 presents the system and threat models. Section 3 introduces preliminaries and notation conventions and formalizes the restricted response and privacy budget models. Section 4 describes the protocol design and core algorithms. Section 5 provides the correctness and security analysis. Section 6 presents the prototype implementation and experimental evaluation results. Finally, Section 7 concludes the paper and discusses future work. The overall architecture of the proposed scheme is illustrated in Figure 1.

2. System and Threat Model

We consider an IoT scenario where terminal devices act as the primary producers of raw data. To adapt to the dynamic nature of IoT data over time, this scheme employs a dynamic commitment mechanism. In each query round t, the device generates a new commitment $[eqn]$ for the current real-time observation value $[eqn]$ . This mechanism ensures that the zero-knowledge proof constraints are always anchored to the current physical reading, thereby supporting effective verification of time-series data and avoiding the logical limitations of static commitments that cannot cover dynamic data. Edge nodes function solely for caching and request scheduling; they are assumed to be malicious and do not maintain any trusted counters or key states. Users initiate restricted queries to the devices, expecting to receive only restricted answers such as threshold judgments, discrete binning, or prefix disclosures. Independent verifiers or auditors can verify the consistency and compliance of each invocation based solely on commitments, zero-knowledge proofs (ZKPs), and chained receipts, without ever accessing the plaintext data or the server’s internal states. The overall system design eliminates reliance on server-side persistent states or TEEs.

Each data record binds a device identifier to a single scalar observation. Instead of raw values, the system returns restricted answers: determining whether a value crosses a given threshold, mapping the value to a preset discrete interval and returning the interval index, or outputting a fixed-length high-order prefix. During the registration phase, the device only generates identity-related keys and publishes the public keys as identity anchors; in each query round t, it independently samples the round’s randomness and generates corresponding evidence and meta-information to be provided along with $[eqn]$ .

The security goals are fourfold: First, privacy accounting: Under multiple interactions regarding the same record, the system must satisfy the composition bound of $[eqn]$ -DP, and the process must halt immediately upon budget exhaustion. Second, verifiability: A verifier, without accessing raw values, must be able to check that the current output is indeed computed from the specific commitment via the declared mechanism, that the privacy budget is not overdrawn, and that the invocation count has not exceeded its limit. Third, auditability: Receipts and proofs must be persistant and replayable, eliminating dependencies on historical session states. Fourth, source authenticity: The verifier must be able to confirm in a publicly verifiable manner that the data source $[eqn]$ participating in the zero-knowledge proof computation is indeed generated by device i holding a legitimate private key and has not been tampered with during transmission.

Regarding the threat model, we define edge nodes and cloud service providers as active attackers. This means that the above entities may not only behave as honest but also be curious to attempt inference but may also deviate from protocol specifications, actively attempt to tamper with receipt chains, forge zero-knowledge proofs, or replay historical credentials to undermine system integrity. Additionally, we assume that different authorized entities may collude, attempting to reconstruct original observations by sharing data. Therefore, the security of this scheme does not rely on the trustworthiness of the infrastructure but is enforced through cryptographic mechanisms (e.g., ZKP, VRF, and hash chains). To ensure source authenticity, this scheme introduces a digital signature mechanism. We assume that devices employ appropriate key protection mechanisms to ensure that stored private keys $[eqn]$ are not leaked. Regarding physical side-channel attacks and source data authenticity issues, this protocol explicitly defines the security boundary: The protocol layer primarily guarantees the privacy and compliance (computational integrity) of the computational process, while key protection at the physical layer and anti-tampering of sensor data are assumed to be guaranteed by the underlying hardware root of trust. Specifically, we assume devices are equipped with industrial-standard hardware security modules (e.g., TPM 2.0 or Secure Element SE) for generating and storing identity private keys $[eqn]$ and commitment randomness $[eqn]$ in an isolated environment. This hardware assumption ensures that even if an attacker physically accesses the device, it is difficult to extract long-term keys through differential power analysis (DPA), thereby providing a trusted anchor for the upper-layer zero-knowledge proof protocol.

The engineering constraints are defined as follows: Computation and proof generation on the device side must maintain a small, constant overhead. The edge node performs only queuing and throttling. Verification can be performed independently at any endpoint without reliance on a trusted time source. Randomness can be derived from a verifiable pseudo-random source. Invocation control employs stateless k-use tokens and generates verifiable receipts. During verification, these are checked alongside the privacy budget: The former constrains frequency and concurrency, while the latter constrains the upper bound of information disclosure.

3. Preliminaries, Notation and Formal Model

3.1. Notation and Public Parameters

The key mathematical notations, cryptographic parameters, and system variables used throughout this paper are summarized in Table 1.

3.2. Interfaces

3.2.1. System Initialization

$$[eqn]$$

Given a security parameter $[eqn]$ , generate public parameters $[eqn]$ , which include the commitment system, hash function, VRF public key, and common reference string for zero-knowledge proofs. This step is typically performed offline by the system deployer.

3.2.2. Device Registration

$$[eqn]$$

When device i first joins the system, it runs a key generation algorithm to establish its digital identity. Specifically, the device generates a digital signature key pair $[eqn]$ for source authentication and a Verifiable Random Function (VRF) key pair $[eqn]$ for constructing unique session indices. Subsequently, the device publishes the public keys $[eqn]$ and $[eqn]$ , along with the negotiated privacy budget parameters $[eqn]$ and invocation limit k, to the registration center as identity anchors. This process establishes the trust root for subsequent interactions without requiring any static data commitments during registration.

3.2.3. Restricted Query

$$[eqn]$$

When the service party initiates the t-th query $[eqn]$ , the device first generates the restricted answer $[eqn]$ according to the specified differential privacy mechanism $[eqn]$ and calculates the dynamic commitment $[eqn]$ for the current observation $[eqn]$ . To ensure data source authenticity and non-repudiation, the device uses the private key $[eqn]$ to digitally sign the tuple $[eqn]$ , generating $[eqn]$ . Finally, the device generates a zero-knowledge proof $[eqn]$ to prove that $[eqn]$ and the committed value $[eqn]$ satisfy the constraint relation of mechanism $[eqn]$ and that privacy budget updates and k-use restrictions comply with regulations.

3.2.4. Online Verification

$$[eqn]$$

The online verifier runs the verification algorithm (detailed in Algorithm 3) on input $[eqn]$ without accessing the raw $[eqn]$ . If the output is 1, the invocation is considered compliant in all three dimensions (mechanism, budget, and k-use) and is recorded into the public transcript T; otherwise, the invocation is rejected.

3.3. Differential Privacy Mechanisms for Restricted Responses

This subsection presents local differential privacy mechanisms for three types of restricted responses $[eqn]$ , and specifies the single-round privacy cost $[eqn]$ and budget update rules for each.

3.3.1. Threshold Judgment

For threshold judgment operations, only answer “whether the current observation exceeds a given threshold.” Given threshold T, the true Boolean answer is

$$[eqn]$$

The local mechanism uses a standard binary randomized response. Given privacy parameter $[eqn]$ , the distribution of output $[eqn]$ is

$$[eqn]$$

This mechanism satisfies $[eqn]$ -local differential privacy. The single-round privacy cost is

$$[eqn]$$

3.3.2. Discrete Binning

For binning operations, we partition the observation domain X into a set of disjoint intervals:

$$[eqn]$$

Only answer “which interval the current observation falls into.” Let the true bucket index be

$$[eqn]$$

where $[eqn]$ contains the specific bucket partition.

The local mechanism uses m-ary randomized response. Given privacy parameter $[eqn]$ , the distribution of output $[eqn]$ is

$$[eqn]$$

This satisfies $[eqn]$ -LDP. The single-round privacy cost is

$$[eqn]$$

3.3.3. Prefix Disclosure

Prefix disclosure targets identifier-like fields (e.g., anonymized IDs, hash values), exposing only the high-order prefix without revealing the complete identifier. Let the original identifier be

$$[eqn]$$

Only the prefix of length ℓ, $[eqn]$ , is considered. The prefix space size is $[eqn]$ . Each prefix can be treated as a bucket index in $[eqn]$ . The true prefix category is denoted $[eqn]$ . For consistency, the prefix mechanism also uses m-ary randomized response, but with an independent privacy parameter $[eqn]$ . The output distribution is

$$[eqn]$$

This distribution has the same form as Equation (8) and thus satisfies $[eqn]$ -LDP. The single-round privacy cost is

$$[eqn]$$

Engineering Trade-offs in Mechanism Selection: For high-dimensional output space scenarios such as bucket and prefix queries, existing research shows that mechanisms like optimized local hash (OLH) typically provide better statistical utility than randomized response (RR) [21]. However, in a verifiable computing architecture, mechanism selection is constrained by the circuit complexity of zero-knowledge proofs. OLH relies on cryptographic hash functions, whose constraint count in arithmetic circuits is typically on the order of $[eqn]$ , which would lead to a significant increase in proof generation time, making it difficult to adapt to resource-constrained IoT terminals. In contrast, the RR mechanism mainly involves lightweight Boolean comparisons and arithmetic operations, with extremely low circuit overhead. Experimental analysis was conducted in Section 6.8. Therefore, this scheme prioritizes RR to ensure system real-time performance and engineering feasibility.

3.3.4. Budget Update and Accounting

For each device or record, let the initial budget be $[eqn]$ , and the balance before the t-th invocation be $[eqn]$ . After executing any of the above mechanisms, the budget is updated as

$$[eqn]$$

If $[eqn]$ , the current invocation should be rejected, and no $[eqn]$ or proof is generated.

Given a history of invocations,

$$[eqn]$$

the differential privacy accountant

$$[eqn]$$

outputs a composition bound $[eqn]$ , where $[eqn]$ is the global $[eqn]$ upper bound and $[eqn]$ is the failure probability upper bound. The accountant can be implemented using basic composition [22], advanced composition, or Rényi-DP [23]; the externally auditable semantics depend only on whether the composition bound is derived from the same Acc.

3.4. Stateless k-Use and Receipt Chain

3.4.1. VRF-Generated Session Index

At the t-th invocation, the DP engine uses VRF [20] to compute on input $[eqn]$ :

$$[eqn]$$

The verifier checks using the public key:

$$[eqn]$$

The session index is constructed from the VRF output $[eqn]$ :

$$[eqn]$$

which uniquely identifies the t-th invocation of device i in the public transcript. Since VRF output is unique and pseudorandom for a given input, the device cannot forge multiple “legitimate-looking” additional invocation records.

3.4.2. Hash-Chained Receipts

Let the public initial receipt be $[eqn]$ . The public metadata for the t-th round is $[eqn]$ . We chain all accepted invocations via a hash chain:

$$[eqn]$$

Thus, each new record is locked onto the previous receipt; if any intermediate record is deleted, inserted, or modified, the subsequent receipts will change. An auditor can simply recompute this formula from the beginning to detect any rollback or tampering by the server.

Additionally, to address potential view-forking attacks in distributed verification environments—where malicious devices present inconsistent receipt chain branches to different verifiers—this protocol recommends a periodic global anchoring mechanism. The system can set a period (e.g., every N rounds or a fixed time window) to force devices to publish their latest chain head receipt $[eqn]$ to a public bulletin board or blockchain smart contract. When verifying, in addition to checking the connectivity of the hash chain, verifiers also need to verify that on-chain records are consistent with public anchors. This preserves the high performance of local verification while eliminating forking threats through eventual consistency.

3.4.3. Stateless k-Use Counting

Since each accepted invocation produces a unique index $[eqn]$ and is linked into the receipt chain, an auditor can simply extract all $[eqn]$ entries for a device i from the public transcript T and count them to determine whether the upper limit k has been exceeded. The entire process does not rely on a server-maintained invocation counter, thus achieving stateless k-use limitation.

3.5. Unified Verification Relation

This subsection compresses three conditions—correct mechanism output, non-overdrawn budget, and adherence to k-use limits—into a unified verification relation R. Each round generates a zero-knowledge proof $[eqn]$ for independent checking by online or offline auditors.

3.5.1. Public Input and Witness

For the t-th record, the public input vector is defined as

$$[eqn]$$

The witness vector is

$$[eqn]$$

where $[eqn]$ is the raw observation of the current round, $[eqn]$ is the temporary randomness (fresh randomness) used to generate the dynamic commitment $[eqn]$ , $[eqn]$ is the internal randomness of the DP mechanism, and  $[eqn]$ is the budget balance before updating. Note that the proof generation process uses $[eqn]$ rather than the static randomness from registration. This ensures that even if $[eqn]$ has the same value in different rounds, its commitment $[eqn]$ is statistically indistinguishable, preventing equality leakage in the ciphertext state.

3.5.2. Three Sub-Predicates

The unified relation consists of the conjunction of three sub-predicates:

1. Mechanism consistency $[eqn]$ : requires consistency between the dynamic commitment and mechanism invocation:

$$[eqn]$$

and $[eqn]$ is generated from $[eqn]$ via the specified DP mechanism.

2. Budget deduction consistency $[eqn]$ : requires that the budget update follow the rules:

$$[eqn]$$

and $[eqn]$ is consistent with the three types of mechanism parameters.

3. Invocation limit and receipt consistency $[eqn]$ : requires correct VRF and receipt chain and that k-use is not exceeded:

$$[eqn]$$

and based on all indexes related to device i in the public transcript, the number of accepted invocations does not exceed k.

3.5.3. Unified Relation and Proof Semantics

Combining the three sub-predicates, the unified verification relation is written as

$$[eqn]$$

The DP engine locally invokes the proof algorithm to generate

$$[eqn]$$

The online verifier or offline auditor executes

$$[eqn]$$

If and only if $[eqn]$ , the invocation is considered compliant in all three dimensions (mechanism execution, budget deduction, and k-use limits) and is written into the public transcript T. In engineering implementations, R can also be split into three sub-relations and proven separately, then aggregated; in this paper, we uniformly denote it as one relation and one proof $[eqn]$ for simplicity.

4. Protocol Design and Algorithms

Based on the formal model, this section details the protocol implementation to ensure mechanism consistency, stateless budget constraints, and independent auditability. Unlike traditional approaches that separate data publication from auditing, we integrate these operations into atomic processes to cryptographically bind query results with budget deductions and invocation indices, effectively preventing ex-post tampering or selective disclosure.

The system workflow initiates with the device registration phase, which establishes the necessary initial states and cryptographic commitments for participating entities. The detailed workflow is presented in Algorithm 1.

The Restricted Query process serves as the core component, simultaneously handling LDP sampling, budget updates, and evidence construction within a single atomic invocation. By utilizing VRFs and ZKPs to certify compliance before data release, it ensures that every query output is verifiable and strictly adheres to system regulations, as detailed in Algorithm 2. Algorithm 1 Register Device

• Input:  Security parameter $[eqn]$ , Device ID i, Total budget $[eqn]$ , Limit k, Public Parameters $[eqn]$
• Output:  Public keys $[eqn]$ , Initial state $[eqn]$
• 1: $[eqn]$
• 2: $[eqn]$             ▹ Generate independent VRF keys
• 3: $[eqn]$
• 4: $[eqn]$                        ▹ Initialize receipt chain
• 5:Store $[eqn]$ using secure mechanism
• 6:Publish $[eqn]$
• 7:return  $[eqn]$

Algorithm 2 Query

• Input: 

$[eqn]$

• Output:  Transmission package $[eqn]$ , Updated state $[eqn]$
• 1: $[eqn]$
• 2:if  $[eqn]$  then
• 3:    return ⊥
• 4: end if
• 5: $[eqn]$
• 6: $[eqn]$
• 7: $[eqn]$
• 8: $[eqn]$
• 9: $[eqn]$        ▹ Dynamic Commitment
• 10: $[eqn]$
• 11: $[eqn]$
• 12: $[eqn]$
• 13: $[eqn]$
• 14: $[eqn]$       ▹ Sign context including t
• 15: $[eqn]$
• 16: $[eqn]$
• 17: $[eqn]$
• 18: $[eqn]$
• 19: $[eqn]$
• 20:return  $[eqn]$

For real-time validation, the online verification process remains stateless and lightweight, enabling any verifier to accept or reject invocations by sequentially checking the VRF output, receipt hash chain, and ZKP validity against public parameters without maintaining historical context. The procedure is shown in Algorithm 3.

Finally, the offline auditing mechanism performs global consistency checks by reconstructing budget consumption trajectories and invocation statistics solely from public transcripts. This enables third parties to independently detect violations such as overdrafts or chain breaks, guaranteeing long-term traceability without accessing device internal states, as outlined in Algorithm 4. Algorithm 3 Verify

• Input:  $[eqn]$ , $[eqn]$
• Output:  $[eqn]$
• 1:Parse $[eqn]$ as $[eqn]$
• 2: $[eqn]$
• 3:Step 1: Source authenticity
• 4:if  $[eqn]$  then
• 5:    return 0              ▹ Invalid signature
• 6:end if
• 7:Step 2: Index uniqueness
• 8:if  $[eqn]$  or  $[eqn]$  then
• 9:    return 0           ▹ Invalid VRF proof or index
• 10:end if
• 11:Step 3: Computational integrity
• 12:if  $[eqn]$  then
• 13:    return 0               ▹ Invalid ZK proof
• 14:end if
• 15:return 1

Algorithm 4 Audit (Replay)

• Input: 

$[eqn]$

• Output:  result, S
• 1:State $[eqn]$ for each i; $[eqn]$ ; $[eqn]$
• 2:for each $[eqn]$  do
• 3:     $[eqn]$
• 4:     $[eqn]$
• 5:    if  $[eqn]$  or  $[eqn]$  then
• 6:        return  $[eqn]$
• 7:    end if
• 8:    if  $[eqn]$  or  $[eqn]$  then
• 9:        return  $[eqn]$
• 10:    end if
• 11:     $[eqn]$
• 12:    if  $[eqn]$  then
• 13:        return  $[eqn]$
• 14:    end if
• 15:     $[eqn]$
• 16:    if  $[eqn]$  then
• 17:         $[eqn]$
• 18:    end if
• 19:     $[eqn]$
• 20:     $[eqn]$ to $[eqn]$ ; $[eqn]$
• 21:    if  $[eqn]$  then
• 22:         $[eqn]$
• 23:        if  $[eqn]$  then
• 24:           return  $[eqn]$
• 25:        end if
• 26:         $[eqn]$
• 27:    end if
• 28: end for
• 29:if  $[eqn]$  and  $[eqn]$  then
• 30:    return  $[eqn]$
• 31: end if
• 32:for each device i do
• 33:     $[eqn]$
• 34:    if  $[eqn]$  then
• 35:         $[eqn]$
• 36:    end if
• 37: end for
• 38:return  $[eqn]$  if  $[eqn]$  else  $[eqn]$

5. Correctness and Security Analysis

5.1. Correctness and Security Statements

Proposition 1. Completeness and Functional Correctness.

Under honest execution of Algorithms 1–3, for each query round, the probability that Verify outputs 1 is at least $[eqn]$ , and the accepted record $[eqn]$ is consistent with the public $[eqn]$ and the mechanism and budget rules given in Section 3.

Proposition 2. Differential Privacy Guarantee.

Let view denote the visible outputs and meta-information of a device in a sequence of T accepted interactions. Applying accountant Acc to this interaction yields a composition bound $[eqn]$ . Then for any adjacent input sequences, view satisfies $[eqn]$ -DP in the local sense.

Proposition 3. Unforgeability and k-Use Limitation.

Under the assumptions of commitment binding, EU-CMA security of digital signatures, VRF pseudorandomness and uniqueness, hash collision resistance, and zero-knowledge proof completeness and soundness, any PPT adversary without knowledge of the device’s internal witness can, with only negligible probability:

• (1)Construct a record that is accepted by Verify but inconsistent with the mechanism or budget rules in Section 3;
• (2)Cause the number of accepted invocations for a device to exceed its limit $[eqn]$ ;
• (3)Generate a public transcript that passes Algorithm 4 audit but contradicts the online Verify conclusion.

5.2. Completeness and Functional Correctness

Theorem 1. Completeness and Functional Correctness.

Under honest execution of Algorithms 1–3, for any round t, we have

$$[eqn]$$

and each accepted record satisfies:

Budget update relation:

$$[eqn]$$

The distribution of restricted answer $[eqn]$ is exactly consistent with the local mechanism corresponding to $[eqn]$ (threshold, binning, or prefix mechanism) in Section 3.3. VRF and hash chain relations:

$$[eqn]$$

Proof. The registration phase (Algorithm 1) primarily establishes the binding relationship between device identity keys $[eqn]$ and privacy policy parameters $[eqn]$ . This phase does not involve static commitments to subsequent real-time observation data. □

In the t-th restricted query (Algorithm 2), the device independently samples random number $[eqn]$ for the current real-time observation value $[eqn]$ , generating a dynamic commitment:

$$[eqn]$$

Based on the computational binding property of the commitment scheme, within polynomial time, an attacker cannot find another distinct input $[eqn]$ such that $[eqn]$ holds. Therefore, the subsequently generated zero-knowledge proof $[eqn]$ can strictly constrain that the restricted answer $[eqn]$ is indeed correctly generated from the true value $[eqn]$ locked by this commitment $[eqn]$ via the specified mechanism.

During the t-th query round, Algorithm 2 first calculates the single-round privacy loss and balance according to the rules in Section 3.3:

$$[eqn]$$

Subsequently, it selects the corresponding local mechanism based on the operation type $[eqn]$ : when $[eqn]$ , $[eqn]$ is sampled according to the Binary Randomized Response distribution given in Section 3; when $[eqn]$ or $[eqn]$ , $[eqn]$ is sampled according to the distributions of the m-ary Randomized Response mechanism and the Prefix Randomized Response mechanism, respectively. Thus, under honest execution, the distribution of $[eqn]$ is strictly consistent with the corresponding mechanisms in Section 3.

In the same round, Algorithm 2 utilizes the VRF and hash function to compute

$$[eqn]$$

It then uses these quantities, together with the budget state, operation parameters, and commitment, as inputs and witnesses for the unified relation R to construct the ZKP $[eqn]$ . From the definition of R in Section 3.5, under honest execution, we have

$$[eqn]$$

The ZKP system satisfies completeness over the relation R, i.e.,

$$[eqn]$$

In Algorithm 3, apart from $[eqn]$ , all other checks are direct verifications of the aforementioned budget update equations, VRF, and hash chain equations. Under honest execution, these checks hold true invariably and do not introduce additional rejection events. Consequently, for any round t, we have

$$[eqn]$$

Moreover, once $[eqn]$ , the budget update, mechanism distribution, and VRF/hash chain relations are all individually satisfied, thereby guaranteeing functional correctness.

5.3. Differential Privacy and Budget Soundness

Lemma 1. Single-Round Local Differential Privacy.

Let the operation in round t be $[eqn]$ , and the single-round privacy strength be

$$[eqn]$$

For any corresponding mechanism M (threshold, binning, or prefix) defined in Section 3.3, and for any pair of adjacent inputs $[eqn]$ , and any output y, we have

$$[eqn]$$

Proof. For the binary threshold mechanism, Section 3.3 gives its randomized response parameter as

$$[eqn]$$

□

When the input bit $[eqn]$ :

$$[eqn]$$ $$[eqn]$$

For any output $[eqn]$ , we have

$$[eqn]$$

Thus, it satisfies $[eqn]$ -LDP.

For the binning and prefix mechanisms, Section 3.3 has already established that for any bin index j, when the input falls into that bin, the probability of outputting $[eqn]$ is

$$[eqn]$$

When the input is not in that bin, the corresponding probability is

$$[eqn]$$

where m is the number of output values. The ratio between the two is

$$[eqn]$$

Therefore, it similarly satisfies the Local $[eqn]$ -DP condition. Since the above inequality holds uniformly for all three types of mechanisms, the lemma follows.

Theorem 2. Budget Soundness and Differential Privacy Composition.

Consider a device involved in T rounds of accepted interactions, where the operation in round t is $[eqn]$ , and the single-round loss is

$$[eqn]$$

Let the output of the differential privacy accountant defined in Equation (17) be

$$[eqn]$$

Then, the overall randomized mapping from the device’s raw observation sequence to the public output sequence satisfies $[eqn]$ -DP in the local sense. Proof. By Lemma 1, for every round t, any adjacent inputs $[eqn]$ , and single-round output $[eqn]$ , we have

$$[eqn]$$

Let the entire output sequence be $[eqn]$ and the two adjacent input sequences be $[eqn]$ and $[eqn]$ . Given the output sequence, the ratio of the joint probabilities for the entire sequence can be written as the product of the single-round ratios:

$$[eqn]$$

The definition of the Accountant Acc in Section 3 ensures that its output $[eqn]$ covers at least the sum of the aforementioned losses, i.e.,

$$[eqn]$$

and provides a corresponding upper bound on the failure probability $[eqn]$ , consistent with the $[eqn]$ form in the standard Differential Privacy Composition Theorem. Replacing the sum in the exponent of the above equation with $[eqn]$ yields that the overall mechanism satisfies Local $[eqn]$ -DP for any device.

5.4. k-Use Limitation and Audit Replayability

Lemma 2. Uniqueness of Index and Receipt Chain.

Assuming the uniqueness of the VRF and the collision resistance of the hash function, for any device identifier i and round t, once the output $[eqn]$ is obtained via

$$[eqn]$$

then

$$[eqn]$$

is uniquely determined. Given the previous receipt $[eqn]$ and meta-information $[eqn]$ , the recursive definition

$$[eqn]$$

is also uniquely determined. If there exist two different sets of $[eqn]$ or $[eqn]$ for the same $[eqn]$ that still pass verification, one could construct a VRF output reuse or a hash collision, which contradicts the assumption.

Theorem 3. k-use Soundness and Audit Equivalence.

Assuming the binding property of commitments, the pseudorandomness and uniqueness of the VRF, the collision resistance of the hash function, and the soundness of the ZKPs, the following hold:

• 1.If the Online Verification Algorithm (Algorithm 3) returns $[eqn]$ for all records of a specific device i, then that device satisfies the budget update rules and k-use limits in all accepted rounds. That is, for every round t,

$$[eqn]$$

it holds, and the total number of accepted invocations does not exceed the preset upper limit $[eqn]$ .

• 2.For any public transcript T, the accept/reject conclusions yielded by the Online Verification Algorithm (Algorithm 3) and the Offline Replay Audit Algorithm (Algorithm 4) for every record in T are completely identical.

Proof. First, we prove the first claim. Assume, for the sake of contradiction, that there exists a record that violates the budget update or k-use conditions in actual execution but still satisfies $[eqn]$ . Let the public input and real witness corresponding to this record be $[eqn]$ ; then, we have

$$[eqn]$$ $$[eqn]$$

By the knowledge soundness of the ZKP, we can extract another witness $[eqn]$ from $[eqn]$ such that

$$[eqn]$$

The unified relation R explicitly incorporates commitment consistency, budget deduction consistency, and k-use conditions. If the actual execution has already violated the budget or invocation limit, then any witness satisfying R must inevitably contradict $[eqn]$ or the equations for $[eqn]$ and $[eqn]$ given in Lemma 2. This implies the construction of an attack that breaks the binding property of the commitment or the security of the VRF/Hash, which contradicts the aforementioned assumptions. Therefore, under these assumptions, the probability of such an event—where a violation occurs yet the verification passes—is at most $[eqn]$ , thereby establishing the soundness of the budget and k-use mechanisms. □

Next, we prove the second claim. Given a public transcript T, the sequence of checks executed by Algorithms 3 and 4 on each record is completely identical. Both involve verifying the VRF proof and checking:

$$[eqn]$$ $$[eqn]$$

and reconstructing the budget and k-use states according to

$$[eqn]$$

Finally, both invoke $[eqn]$ . All the aforementioned judgments rely solely on the public fields in T and the states derived from the prefix; they are deterministic computations that do not depend on the device’s internal randomness or private information. Consequently, for the same transcript T, the accept/reject conclusions yielded by the two algorithms for each record must be identical.

6. Implementation and Experimental Evaluation

6.1. Prototype Implementation

Our reference implementation consists of three parts: a device-side library, an edge relay, and a public verifier. The device-side library encapsulates all logic of Algorithms 1 and 2: During registration, it generates device keys and initial receipts; during each query, it generates dynamic commitments for current observations and constructs proofs; during queries, it derives session randomness from a PRF, produces restricted answers via lightweight mechanisms (threshold, binning, or prefix), and packages the joint predicate of mechanism consistency, budget deduction, and k-use into a zero-knowledge proof. Randomization within the library relies only on local PRF and cryptographic-grade pseudorandom sources, without accessing external states. The edge relay is only responsible for forwarding, rate limiting, and buffering; it does not participate in trusted computation nor maintain persistent counters; its message formats in both directions are completely public, facilitating packet capture and replay. The public verifier implements Algorithms 3 and 4 and can replay transcripts offline on any endpoint, reconstruct budget trajectories and receipt chains, and independently render acceptance conclusions.

Cryptographic instantiation follows the principle of choosing the best inside and outside circuits: Commitments use an additively homomorphic scheme for efficient inside circuits; hash functions use constraint-friendly constructions inside circuits and mature collision-resistant algorithms outside circuits; VRF is a standardized implementation for independent deployment and audit reproduction. The proof system only requires completeness, knowledge soundness, and zero-knowledge; the specific backend can be replaced without affecting interfaces and audit processes. All choices are constrained by constant overhead on the device and edge sides, avoiding loops proportional to the size of specific numerical domains.

The interaction relationships among system components and the client verification pipeline are shown in Figure 2.

6.2. Experimental Environment

Experiments were conducted on a 16-core x86-64 server (3.4 GHz, 64 GB RAM, Ubuntu 22.04, kernel 5.15). The cryptographic layer uses SNARK construction on the BLS12-381 curve; the in-circuit hash uses Poseidon; budget commitment is based on the Pedersen scheme on the Jubjub curve; the session index/randomness source uses ECVRF; and the receipt chain is a hash chain. The system is compiled with Rust 1.75, with OpenSSL 3.x supporting random numbers and hashing; each experiment warms up for 30 s, the sampling window is 3 min, and the results are the median of five independent runs. The cryptographic primitives and components used are detailed in Table 2.

6.3. Data and Workload

We tested system performance on two de-identified datasets: R-1 with about 1.2 million rows containing non-negative monetary fields and R-2 with about 8.4 million rows containing heavy-tailed usage fields. Additionally, three types of synthetic columns were generated: Gaussian N (0, 1) distribution, log-normal ( $[eqn]$ ) distribution, and Zipf distribution (range $[eqn]$ , exponent $[eqn]$ ). The value distributions are visualized in Figure 3. Experiments set three operators: threshold, binning, and prefix; number of buckets $[eqn]$ ; prefix length $[eqn]$ ; and concurrency streams 1, 8, and 16. Each k-use token’s authorization limit is $[eqn]$ . These settings cover typical end-edge scenarios from single stream to high concurrency, as summarized in Table 3.

6.4. Evaluation Metrics

System metrics include throughput and p50/p95 end-to-end latency, with separate breakdowns of device-side generation latency and verifier verification latency, allowing proof-related overhead to be separated from network/business overhead. Evidence chain metrics include single receipt size, VRF verification cost, and receipt chain growth rate. Differential privacy accuracy metrics depend on the task: threshold judgment reports ROC and true positive/false positive at target operating points; binning reports macro accuracy and mean absolute bucket error; prefix use case reports prefix matching error rate and re-identification rate under multi-round synthesis. Audit-related metrics report offline replay speed (verification CPU/memory per thousand transcript records) and receipt chain scanning cost under different time window lengths. All charts report the median of five independent runs; error bars are 95% bootstrap confidence intervals (1000 resamples). Latency statistics are sampled after a 30 s warm-up over a 3 min window.

6.5. Baselines

To attribute the cost and benefit of evidence generation, evaluation includes three baselines. The first is proof-free local differential privacy, producing only restricted answers without proofs of mechanism consistency and budget deduction, and the verifier does not check receipt chains; this baseline gives the accuracy upper bound and cost lower bound of randomization only. The second is the server-state counting version, where invocation counts are accumulated and rate-limited on a server-side counter without generating receipt chains; it represents a common engineering alternative but cannot be audited offline. The third is differential-privacy-free threshold/binning, only for functional reference, showing the ultimate accuracy without budget constraints. Our method and the three baselines are aligned on the same task, same parameters, and same network conditions, reporting differences in throughput, latency, evidence size, and verification cost, allowing readers to directly see the marginal cost from claim to evidence. A summary comparison of these methods is provided in Table 4.

6.6. Experimental Procedure

Each experiment fixes a task, an output domain, and a privacy/invocation budget configuration. The system first completes registration, generating commitments and registering public metadata, and then enters multiple invocation rounds, each producing a restricted answer and proof, delivered via the edge relay to the verifier. The verifier performs online acceptance, recording whether it passed and various latencies; after the experiment, an offline audit is run immediately, replaying Algorithm 3 based on the transcript, reconstructing budget trajectories, and checking whether balances are consistent with online records. Privacy parameters are scanned over a preset grid, covering low, medium, and high $[eqn]$ configurations; bin categories from small to medium range; and prefix lengths from very short to medium. Invocation limit k takes several typical values and combines with the privacy budget to form a dual-gate strategy. To avoid cache and warm-up effects affecting results, all curves are sampled in stable phases.

6.7. Results Interpretation

Under end/edge constraints, proof generation and verification overhead are constant-level, mainly determined by the fixed gate count of the chosen proof system, with no linear relationship to input domain size. The p95 end-to-end latency is less sensitive to $[eqn]$ ; the impact of bin category count and prefix length mainly comes from the fixed overhead of encoding and proof circuits. Compared with the proof-free local differential privacy baseline, our method shows a stable but predictable constant-factor increase in throughput and latency; compared with the server-state counting baseline, our method has similar online throughput, but offline audit accessibility is significantly stronger, and cross-node replay does not require access to server historical states. Evidence size grows linearly with invocation count, but the slope is dominated by receipt chain digest length and does not expand with data domain size; single-core verification speed on the audit side is approximately linear with workload scale, decoupled from the number of edges and devices, making large-scale offline audits computationally and storage feasible. As shown in Table 5, replay audit throughput reaches about 23 k–25 k QPS. This high performance, about 15 times the single verification speed, is directly attributed to the batch verification strategy.

To more intuitively observe the performance overhead of different operators in a single operation, we measured their proof sizes and verification times, as shown in Figure 4.

Results show that the prefix series has significantly lower overhead on the verification side than the bucket series, while bucket-1024 has the highest constant term in proof size. Overall, the cost fluctuations of each operator remain at the millisecond level and mainly vary with circuit structure, unaffected by specific data scale.

Energy Consumption and Feasibility Analysis

Given the sensitivity of IoT devices to battery life, we further evaluated the energy consumption overhead of the scheme based on measured latency data and a standard hardware power model. According to our microbenchmark tests (as shown in Figure 5), the proof generation latency for a single restricted query remains stable at around 10.8 ms. Referring to energy consumption benchmark studies for similar embedded platforms (ESP32-WROOM-32, main frequency 240 MHz) [30], at a working voltage of 3.3 V and average working current of 160 mA, the estimated energy consumption for this level of computational task is approximately 5.7 mJ.

As a comparison, existing IoT communication energy consumption research [31] indicates that the energy consumption for establishing a connection via Wi-Fi or NB-IoT and sending a single standard MTU data packet is typically between 100 mJ and 300 mJ and is significantly affected by signal quality. This shows that the computational energy consumption introduced by this scheme is only 2% to 5% of the single wireless transmission energy consumption. Therefore, the “Computation-for-Communication” strategy adopted in this scheme—i.e., compressing high-dimensional raw data into constant-size zero-knowledge proofs and short receipts through local computation—has significant advantages in reducing radio active time, demonstrating its engineering feasibility in battery-powered constrained environments.

In terms of accuracy, threshold tasks maintain stable ROC shapes with adequate separation between true and false positives, as shown in Figure 6. Binning tasks shows controllable mean absolute bucket errors within medium category ranges, while prefix lengths should be restricted to mitigate potential linkage risks with binning. Experiments on collusion and splicing attacks demonstrate that re-identification rates are effectively constrained by the dual-gate mechanism; queries are rejected once the cumulative leakage reaches the audit bound, consistent with the theoretical analysis in Section 5.

To provide quantitative guidance for parameter configuration in actual deployment, we further evaluated the sensitivity of privacy budget $[eqn]$ in the range [0.1, 1.6] under threshold judgment tasks (as shown in Figure 5). Experiments found that proof generation latency is significantly insensitive to changes in privacy budget, remaining constant across the evaluated range. Theoretically, this is because adjusting $[eqn]$ only changes the public input values of the circuit, without altering the number of gate constraints or the topology of the circuit, so the device-side FFT and MSM computational load remains constant. In contrast, the true positive rate of data shows the expected sigmoid growth pattern: In the strong privacy region $[eqn]$ , TPR is close to random guessing, while in the $[eqn]$ range, TPR rapidly climbs to the highly usable range of 0.70–0.77.

In end-to-end scenarios, we further compared the throughput performance of different operation modes under different concurrency scales, as shown in Figure 7 and Table 6.

It can be seen that as concurrency increases from 1 to 8 and 16, the throughput improvement of server-counter mode is more significant, while stateless k-use and ORE range-only mainly maintain a more stable high plateau range. Overall, each mode maintains expected scalability as concurrency grows, with no obvious bottlenecks. Additionally, a detailed analysis of proof size and verification time versus domain size is provided in Figure 8.

6.8. Performance-Utility Trade-Off Analysis and Hybrid Mechanism Exploration

To further validate the rationale for selecting the Randomized Response (RR) mechanism on resource-constrained IoT devices and explore optimization paths for high-dimensional query scenarios, this section conducts a quantitative trade-off analysis between the RR and Optimized Local Hashing (OLH) mechanisms. The experiment sets a privacy budget of $[eqn]$ , a sample size of $[eqn]$ , and selects four typical bucket sizes $[eqn]$ , focusing on two core metrics: The Mean Squared Error (MSE) reflecting data utility and the zero-knowledge proof generation time (Proving Time) reflecting computational overhead.

As shown in Figure 9, the experimental results exhibit significant Pareto trade-off characteristics:

Performance Dimension: The RR mechanism (blue dots) adopted in this paper demonstrates extremely high computational efficiency, with proof generation time stabilizing around 11 ms, showing almost no fluctuation as the bucket count B increases. In contrast, the OLH mechanism (red dots), due to its reliance on cryptographic hash functions such as Poseidon, incurs a significantly higher number of constraints in arithmetic circuits compared with the simple Boolean operations of RR, leading to proof generation times as high as 45–50 ms, approximately 4–5 times that of RR.

Utility Dimension: As B increases from 16 to 1024, the MSE of RR shows a linear growth trend, indicating that its utility is indeed limited when publishing high-dimensional data; whereas the MSE of OLH remains at a low and stable level, unaffected by dimensionality.

The experimental data clearly delineate an “IoT High-Efficiency Zone”. In the most common low-dimensional, high-frequency query scenarios in IoT (such as threshold judgments with $[eqn]$ or coarse-grained state classification), the RR mechanism achieves a several-fold performance improvement at the cost of minimal utility loss, making it the optimal solution under current engineering conditions.

Based on this analysis, we propose a future evolution direction of a “Hybrid Mechanism”: the system can dynamically switch mechanisms based on the dimensionality of the query request. When $[eqn]$ , RR is prioritized to ensure real-time performance and low energy consumption; when $[eqn]$ , the system automatically switches to the OLH mechanism to maintain the statistical utility of high-dimensional data. Thanks to the unified verification relation $[eqn]$ proposed in this paper, this switching can be seamlessly implemented without altering the underlying verification architecture.

6.9. Related Work Comparative Analysis

To clarify the position of our scheme in existing verifiable differential privacy research, we select representative recent works for quantitative comparison from two dimensions: verification time and proof system scale. The comparison results are summarized in Table 7 and Table 8. Our work builds upon foundational zero-knowledge proof systems [32,33] and range proof techniques [34], extending them to support verifiable differential privacy operations in IoT settings.

6.10. Threats and Limitations

Experiments do not cover device source value forgery and physical side-channel leakage; these risks require other layers of measures. Network simulation can only approximate congestion and packet loss distributions in real operational environments, possibly underestimating tail latency in extreme cases. The proof backend and primitive implementation can be replaced; different choices change constant factors and engineering performance but do not alter verification semantics and audit processes.

7. Conclusions and Future Work

Starting from the engineering reality of IoT end-edge-cloud collaboration, this paper proposes a unified framework of “restricted answers + verifiable evidence”. On the end/edge side, we use lightweight randomization mechanisms to generate restricted answers for operators such as threshold judgment, binning statistics, and prefix disclosure. At the policy level, we introduce auditable privacy budgets and k-use upper limits, forming dual gates: constraining invocation counts and cumulative leakage. At the evidence level, we combine commitments, hashes, and VRF-derived indexes to construct chained receipts, compressing each accepted invocation into a publicly replayable evidence entry. At the verification level, a unified verification relation links mechanism consistency, budget deduction consistency, and invocation limit consistency, enabling any party to independently check compliance without accessing raw data and supporting transcript-based offline audits.

Based on these results, three conclusions can be drawn: First, unifying externally visible behaviors into a single verification relation can transform “whether privacy/invocation policies are followed” into a machine-auditable factual judgment, thereby weakening dependence on server persistent states and trusted hardware. Second, under practical privacy budgets and medium output domains, the constant overhead of proofs and receipt chains is mainly controlled by the proof system gate count and hash digest length, approximately decoupled from specific data domain scale, making large-scale offline audits feasible in both computation and storage. Third, by combining deductible privacy budgets and k-use limits into dual gates, the feasible window for cross-subject, cross-round splicing attacks can be explicitly defined, providing regulators and data providers with a clear “splicing upper bound.”

Looking ahead, there are three directions worth further exploration: First, introducing adaptive accounting and policy tuning during operation so that the budget cost per invocation and the precision required by business can be automatically calibrated. Second, exploring more proof backends and hash/VRF combinations for different hardware and deployment environments, reducing end/edge latency and resource consumption while maintaining semantic equivalence. Third, extending to multi-attribute and temporal features while keeping the unified verification relation semantics unchanged, supporting more complex composite threshold, binning, and prefix operators, and overlaying with centralized statistical aggregation mechanisms, providing infrastructure for cross-organization data collaboration that meets compliance requirements and possesses verifiable evidence chains.

Overall, this paper transforms platform commitments into evidence obligations and privacy boundaries into machine-auditable composition upper bounds, providing a robust engineering path for cross-organization data collaboration in IoT. We hope this method can form a positive cycle with industry compliance requirements, standardization efforts, and open-source ecosystems, promoting the practice of minimal usable information + verifiable evidence to become the new norm for IoT data sharing.