arXiv CSopen access

DARTIC: Decentralized Anonymous Reputation at Scale for Trustworthy Crowdsourcing

1

DARTIC: Decentralized Anonymous Reputation at Scale for Trustworthy Crowdsourcing

arXiv:2605.18146v1 [cs.CR] 18 May 2026

Mouhamed Amine Bouchiha, Member, IEEE, Mourad Rabah, Ronan Champagnat, Abdelaziz Amara Korba, Member, IEEE, Yacine Ghamri-Doudane, Senior Member, IEEE

Abstract—On-chain crowdsourcing leverages blockchain’s decentralization, transparency, and tamper-resistance to build trustworthy and verifiable Web3 crowdsourced services. However, existing decentralized reputation frameworks do not reconcile anonymity, reputation binding, and scalability. This paper demonstrates how on-chain crowdsourcing can simultaneously achieve these requirements under a trust-minimized model. We introduce DARTIC, a decentralized, anonymous, and scalable reputation-driven framework for crowdsourcing. DARTIC presents a dual-ledger system that enables requesters and workers to use distinct pseudonyms across interactions, ensuring unlinkability while maintaining accountability. To mitigate Sybil and reputation-reset attacks, we employ zkSNARKbased set membership proofs, cryptographically binding all user pseudonyms to a single access token without revealing the linkage. For scalability, we investigate two aggregation techniques that compress multiple proofs into a single succinct proof to minimize verification overhead. In addition, we design an automated, privacy-preserving reputation model that dynamically evaluates contributions across diverse crowdsourcing contexts. To demonstrate practicality, we instantiate and assess DARTIC in both crowdsensing and federated learning scenarios. Experimental results show that (i) individual proof generation for token spending completes in less than 3s, (ii) aggregation reduces the verification time of 1024 proofs from 8.7s to 0.96s, and (iii) zkbatching lowers gas costs by more than 100× compared to a pure Layer-1 deployment. These results demonstrate that anonymity, robust reputation binding, and scalability can be jointly achieved in fully decentralized crowdsourcing systems. Index Terms—Crowdsourcing, Web3 Services, Blockchain, Anonymous Reputation, zkSNARKs

Privacy,

I. I NTRODUCTION

W

EB3-enabled crowdsourcing [1], [2] is an emerging class of decentralized service computing systems [3], where a blockchain network coordinates, validates, and enforces service interactions between requesters and providers (aka workers) without relying on centralized intermediaries. Unlike traditional crowdsourcing platforms, where service discovery, execution, and trust management are centrally controlled, Web3-based models decentralize service orchestration, enhancing transparency, security, and fault tolerance [1], [4], [5]. In this paradigm, crowdsourcing tasks can be modeled M. A. Bouchiha is with SAMOVAR, Telecom-SudParis, Paris, France e-mail ([email protected]), M. Rabah, R. Champagnat, Y. and Ghamri-Doudane, are with L3i, La Rochelle University, France email: {mourad.rabah, ronan.champagnat, yacine.ghamri. A. Amara Korba is with the Department of Computer Science, German University of Technology in Oman (GUtech), Muscat, Oman (e-mail: [email protected])

as service provisioning workflows, where workers offer ondemand services and requesters consume them under qualityof-service expectations. A fundamental challenge in such decentralized ecosystems is trust establishment among mutually distrustful participants. Reputation-driven blockchain-based crowdsourcing [6], [7] has emerged as a promising approach to support trust-aware task allocation and incentive-compatible service execution. In these systems, workers—and in some cases requesters—are assigned reputation scores that influence task assignment, pricing, and rewards [8], [9]. Reputation acts as a soft-state quality indicator complementing functional service descriptions [10]. However, existing frameworks remain vulnerable to strategic manipulation, including whitewashing (aka reset), self-promotion, and bad-collision attacks [7]. To mitigate such threats, many solutions bind reputation to static identifiers such as addresses, certificates, or public keys. While effective for accountability, this approach undermines privacy and discourages honest feedback, as participants may fear retaliation, deanonymization, or long-term profiling. Blockchain-based privacy-preserving reputation mechanisms enhance decentralized trust by protecting reputation data privacy (e.g., ratings and computation inputs) [7]. However, user privacy remains largely unaddressed. Due to blockchain’s transparency, on-chain interactions can reveal behavioral patterns and transaction links, enabling traceability and potential deanonymization even when reputation values are hidden. In crowdsensing, such visibility may also encourage free-riding [11], while public feedback can expose evaluators to retaliation. Although automated, feedback-free models [1], [12] reduce direct exposure of ratings, binding reputation to persistent identifiers or master keys still permits long-term tracking. Integrating cryptographic primitives such as zero-knowledge proofs with blockchain platforms [13], [14] offers a promising avenue for building systems that balance privacy and accountability. Yet, current frameworks remain limited. Many solutions [2], [5], [15] rely on centralized authorities to manage identity credentials, thus introducing trusted intermediaries and preventing a fully trust-minimized design. Others leverage privacy-enhancing blockchains [16]– [18], but do not simultaneously address scalability, costefficiency, and automated evaluation with secure integration of real-world service data. These gaps raise the following central research question. How can decentralized crowdsourcing reconcile anonymity, reputation binding, and scalability without relying on trusted authorities?

2

Addressing this question requires overcoming three fundamental tensions: (i) anonymity vs. accountability, (ii) decentralization vs. efficient identity management, and (iii) privacypreserving verification vs. on-chain scalability. To resolve these tensions, we propose DARTIC, a decentralized, anonymous, and reputation-driven crowdsourcing framework. Table I positions DARTIC with respect to prior work. Unlike existing solutions, DARTIC jointly achieves: (i) trustless reputation binding without persistent identifiers, (ii) fully decentralized and automated reputation, and (iii) scalable on-chain verification. The main contributions of this work are summarized as follows: • Decoupled identity and service management for trustless reputation binding. We design a dual-ledger architecture that separates identity control from service interactions, enabling privacy-preserving execution while ensuring Sybil resistance via zkSNARK proofs, decentralized oracles, and threshold cryptography, eliminating reliance on trusted authorities. • Unlinkable pseudonymous participation with contextual accountability. DARTIC allows requesters and workers to generate multiple pseudonyms while cryptographically binding them to a single access token. This design preserves unlinkability across interactions while preventing whitewashing. • Automated and privacy-preserving reputation evaluation. We introduce a general reputation model driven by verifiable service execution outcomes rather than explicit feedback. This reduces retaliation and manipulation risks while maintaining accountability and resistance to strategic behavior. • Scalable verification through proof aggregation and Layer2 execution. To ensure practical deployability, we integrate batching and aggregation mechanisms, significantly reducing on-chain verification overhead and transaction costs while preserving security guarantees. The remainder of this paper is organized as follows. §II reviews related work. §III presents the proposed DARTIC framework. §IV details its protocols. §V provides theoretical analysis, while §VI discusses performance evaluation. Finally, §VII concludes the paper. II. R ELATED W ORK Blockchain-Based Reputation Systems with Centralized or Semi-Trusted Authorities. Several works employ blockchain to ensure transparency and verifiability while relying on semitrusted or centralized entities for identity and credential management. Liu et al. [13] present an anonymous reputation system for industrial retail IoT marketing, using PoS-enabled smart contracts, randomizable signatures, and non-interactive zero-knowledge proofs to guarantee anonymity. However, the Identity Management (IDM) system presents a single point of failure and a trust issue. Similarly, Zhao et al. [5] propose a privacy-preserving blockchain-based mobile crowdsensing reputation framework using additive secret sharing and delegation sets. While smart contracts update global scores transparently, the model assumes a semi-honest Task Distribution Center (TDC) and a fully trusted Key Distribution Center (KDC). Chen et al. [15] adopt a three-layer architecture (task publishing, reputation management, computation) with blind

and group signatures to anonymize workers, and a Shapley value-based mechanism for fair reward distribution. Despite advanced defenses against malicious workers and collusion, reliance on an honest but curious model restricts applicability. Lightweight Privacy-Preserving Approaches in Crowdsourcing and Crowdsensing. Focusing on efficiency in constrained environments, Deng et al. [18] propose a blockchain-based recruitment scheme using Pedersen commitments and CLSAG ring signatures. While lightweight and privacy-preserving, it assumes unbiased requester evaluations and overlooks systemic barriers to consistent worker participation. TrustWorker [2] introduces a secure two-party protocol to compare worker reputations without disclosure, offering privacy with low overhead. Nonetheless, it ignores requester reputations and assumes semi-honest adversaries with static ID bindings, potentially reducing adaptability in dynamic ecosystems. Advanced Cryptographic Integration for Privacy and Verifiability. FedCrowd [21] presents an innovative integration of federated crowdsourcing with blockchain for privacypreserving task recommendation. While privacy is addressed through encrypted task queries, the model primarily focuses on protecting task attributes rather than ensuring the longterm anonymity and unlinkability of workers. AVeCQ [20] exemplifies the integration of advanced cryptography into blockchain-based crowdsourcing. Built on Ethereum smart contracts, it combines zkSNARKs for verifiable quality proofs, Pedersen commitments for homomorphic updates, and Merkle trees for membership verification. Its semi-honest Registration Authority (RA) balances decentralization with efficiency, but trust poses a potential risk. Across these systems and others [4], [19], [22], [23], blockchain serves as a verifiable, tamper-resistant ledger, and privacy is enforced through signatures, commitments, encryption, or zero-knowledge proofs. However, most frameworks retain semi-trusted or centralized authorities (e.g., IDM, KDC, TPC, RA), posing trust and centralization issues. Furthermore, many assume benign evaluator behavior and semi-honest adversaries, assumptions that may not hold in practice when facing collusion, biased evaluations, or reputation attacks. We address these gaps in this work by introducing DARTIC, a fully decentralized, anonymous, and reputation-driven framework for crowdsourcing. To achieve end-to-end decentralization and secure integration of real-world data, DARTIC leverages a dual-ledger architecture alongside a decentralized oracle network, supported by a privacy-preserving protocol [24]. The system enables users to interact anonymously under multiple pseudonyms while maintaining a robust reputation through Merkle trees and scalable zkSNARK constructions. Combined with an automated evaluation, this design ensures that honest users retain their earned reputation by mitigating Sybil and reputational attacks (e.g., bad-mouthing and self-promotion). Collectively, these features establish DARTIC as a robust and practical solution for decentralized, anonymous, and verifiable crowdsourcing in real-world settings.

3

TABLE I: DARTIC vs. related privacy-preserving/anonymous reputation systems. e enc

r efe

R Gao et al. [2] Zhao et al. [5] Liu et al. [13] Dimitriou [16] Deng et al. [18] Chen et al. [15] Duan et al. [19] Koutsos et al. [20] DARTIC

t rea Th del o M S-H S-H Mal. S-H/Mal. S-H/Mal. S-H S-H/Mal. S-H/Mal. Mal.

n sio llu ce Co istan s Re # G G #

G # # G G #

s tles

n atio put ing e R ind B

# # # # G G # # # G #

ID ID ID ID Pseudo Pseudo ID ID Pseudo

s Tru

n atio n put gatio e R re g Ag W-Sum Mean Sum Sum W-Mean W-Sum Sum+DP Sum PW-Mean

ltiMu eud Ps

# # # #

) y n tee ilit tio Ra ty / r tab uta ation n te mi p u a e co R tom (R ony Ac An Au # # # # G # # # G # G # # # G # # G # G #

lity

abi

l Sca

# # # # G #

*

G #

Symbols: = Full support; G #= Partial; #= No support. Mal. = Malicious; S-H = Semi-honest; PW = Piecewise Weighted; DP = Differential Privacy. ∗ Achieves scalability but remains centralized. DARTIC uniquely combines scalable trustless decentralization and fully automated reputation, with strong anonymity guarantees for both raters and ratees.

TABLE II: Summary of key notations used in DARTIC. Notation

Description

AT RT u, v CS = {cni } Mpk , Msk Mcred σcred ctx (apku , asku ) Ru Wf Tv cmA cmR ACT ree RCT ree DCT ree COMM(·) pkcs skcs σorc

Access Token Reputation Token Users participating in crowdsourcing Set of IDML committee nodes Master public and private keys of a user Master credential issued by IDML Committee signature on Mcred Application-specific context Address public/private key pair Reputation score of user u Interaction weighting function Contribution from a worker v Commitment to an access credential Commitment to a reputation credential Merkle tree of access commitments Merkle tree of reputation commitments Merkle tree of deposit commitments Cryptographic commitment function Public key of IDML committee Secret signing key of IDML committee Threshold signature generated by DON

III. DARTIC F RAMEWORK This section presents the proposed DARTIC. We first describe the system model and then outline the architecture and interaction workflow (Fig. 1) that each user follows to ensure privacy preservation and reputation protection. Table II summarizes the main notations used throughout the paper. A. System Model 1. Entities. DARTIC comprises four distinct entities: • Requesters: are the initiators of tasks within the system. They define the requirements, parameters, and rewards associated with the tasks. • Workers: users who take on tasks posted by requesters. Workers build their reputation within the system based on the quality of their submissions, which influences their ability to access higher-value or more challenging tasks. • Validators: a.k.a. committee nodes run a blockchain consensus protocol to agree on the validity of blocks containing identity and business transactions. • Oracles: act as bridges between the blockchain and external data or events to enable the on-chain crowdsourcing system to interact with off-chain data sources.

Requesters and workers can create as many pseudonyms as they like, but all of them must be bound to the same long-term master key to prevent Sybil and reputation attacks. This allows a user to have a unique reputation but use different pseudonyms when interacting with other users. To this end, we assume an IDentity Management Ledger (IDML)– a blockchain committee that verifies identities and ensures their uniqueness [25], [26]. In addition, we have a CrowdSourcing Management Ledger (CSML)–an open permissioned blockchain to manage the on-chain reputation-driven crowdsourcing. We discuss these two components in §III-B. 2. Adversarial Model. We assume that all entities, requesters, workers, validators, and oracles, can exhibit faulty or malicious behavior. No actor is assumed to possess inherent trust, and both workers and requesters are driven primarily by selfinterest, potentially engaging in disruptive actions or colluding to execute coordinated attacks. We assume n ≥ 3f + 1 nodes, ensuring Byzantine tolerance of up to f faults. Specifically, the IDML, CSML, and oracle networks are assumed to follow the protocol execution while tolerating Byzantine faults under a standard model [27]. In this model, participants may behave dishonestly, provided that the number of faulty nodes does not exceed the resilience bound f < 13 . 3. Security Properties. Under the above assumptions, we summarize our security properties (analyzed in §V) as follows: • Sybil resistance: A single user cannot create multiple false identities to exert undue influence or control. • Collusion resistance: The ability to prevent a malicious group of participants from collectively compromising the system. With respect to identity, it ensures that even if a user (prover) and a subset of committee nodes (verifiers) conspire to manipulate the outcome of a decision about the right to access, they cannot succeed without compromising a significant fraction of the system’s security assumptions. • User privacy: An adversary cannot determine a user’s attributes by examining issued credentials, analyzing transaction data during interactions with other users, or observing the ongoing evaluation of interactions. • Unlinkability: This property ensures that the identity of a user cannot be linked to any of its pseudonyms, nor can two pseudonyms of the same user be linked to each other. • Accountability: Actions of participants are traceable to their digital identities in a verifiable manner. Any misbehavior

4

DON

ISC

IDML

1.2 1.4

2.2

On-Chain Events

Invoke ISC

Off-Chain Data

1.3

External Systems

Off-Chain Events

4.1

e.g., SSA, DDP

e.g., SSN validity attestation

IDML Committe

1.1 Register 2.1 mint AT

Master & Context Credentials

1.5

3

2.3

Invoke ISC: Synchronization

4.2

Invoke RSC & DSC: Reputation & Payment Update

ISC, BSC, RSC, ASC, DSC

CSML

submit pseudonymous TXs

submit pseudonymous TXs

e.g., spend AT, spend RT, withdraw, post a new task using

e.g., spend AT, mint RT, use RT, subscribe to a task using

Requester Open Permissioned BC

3

Worker

Fig. 1: DARTIC Framework: DON denotes decentralized oracle network, smart contracts (SCs) names are, ISC: identity, BSC: business, RSC: reputation, ASC: access and DSC: deposit; AT and RT denote access and reputation tokens; SSA and SSN denote social security administration and number; DDP refers to a decentralized dispute protocol. can be detected and appropriately sanctioned without compromising honest users’ privacy. • Reputation binding: A user’s reputation is tied to its actual behavior. Although users can generate multiple pseudonyms, all are cryptographically linked to a unique access token. • Forward Reputation binding: No user should be able to mint/use a reputation token with a reputation score higher than that linked to his/her most recent token. B. Architecture We now present DARTIC design as depicted in Fig.1 and outline the workflow between users and key components. 1. IDentity Management Ledger (IDML). IDML is a consortium blockchain that manages data about Decentralized IDentifiers (DIDs) and acts as credentials issuer. DIDs are publicly identifiable endpoints, such as documents, wallets, smart contracts, etc. We adapt the CanDID [25] approach to uniquely identify legitimate users. The system relies on a PKIlike infrastructure [28] to support the use of DIDs. Each user manages a master public/private key pair (Mpk , Msk ). The PKI infrastructure then stores the correspondence between the DIDs and the public key. We use a permissioned model to issue credentials, in which a set of selected nodes acts as a committee. Let CS be the committee set with n nodes: {cni }ni=1 . The nodes in the committee jointly store a secret key skcs , which is used to issue credentials. The corresponding public key pkcs is used to verify credentials. Any party (e.g., smart contract, validator) can act as a credential verifier. IDML derives Sybil-resistant, privacy-preserving decentralized credentials from commonly used legacy data (Step 1 in Fig.1). To this end, it first transforms a set of claims referred to as “pre-credentials” to a master credential Mcred = (Mpk , σcred ) with a privacy-preserving deduplication protocol [25]. Master credentials are Sybil-resistant because users can only get one credential and are not intended for interactions. Rather, IDML allows users with a valid Mcred to create context-based credentials by linking application-specific attributes (attested to by pre-credentials) to Mcred . The next

step, therefore, consists of the creation of these contextual credentials, where each application (e.g., crowdsensing) defines a distinct context ctx. For instance, if Alice wants to obtain a credential within ctx, she must submit her Mcred to the committee, along with a set of required claims specified by ctx (e.g., age over 18). The committee proceeds to validate the claims and issue a credential for ctx through a process similar to that used to issue Mcred . The detailed registration with credential issuance is formally presented in §IV-B. 2. Crowdsourcing Management Ledger (CSML). CSML is an open permissioned [29] blockchain that implements the crowdsourcing logic. Access to CSML ( Step 2-3 in Fig.1) is done using contextual (application-based) credentials provided by the IDML committee after successful registration. Therefore, within our design, multiple CSMLs with various business logic can be incorporated with the IDML. For instance, we can have a CSML for sensing and another for learning. Users on each CSML can generate as many pseudonyms as they want (ideally, a new pseudo for each new interaction) to protect their identity. To achieve this while ensuring effective reputation and preventing reputation attacks, users must provide verifiable proofs (see §IV-C for the formal constructions). In addition to its business logic, CSML also incorporates the reputation model of DARTIC, which evaluates interactions between users and updates their reputation scores. This model must preserve user privacy as reputation or recommendation systems that rely on users’ historical interactions can inadvertently reveal sensitive information. Consequently, only parameters that do not compromise privacy can be used to evaluate interactions. In DARTIC, the sole parameter reflecting past interactions is the user’s current reputation score. 3. Decentralized Oracle Network (DON). Traditional blockchains are known for “The Oracle Problem”, which refers to the problem of securely integrating real-world data on-chain since blockchains primarily deal with information that is native to the network [30]. Specifically, smart contracts that run “on-chain” cannot process external “off-chain” data and events to provide the user with functionality that needs to be realized outside the blockchain. Consequently, solving this problem is crucial to guarantee the security of the off-chain data we want to process on-chain (Steps 1.4, 2.3, 2.4 in Fig.1). Over the past years, various decentralized oracle protocols have emerged to address this limitation. Among them, two protocols, DECO [24] and Town Crier [31], have been developed specifically to enable oracle nodes to securely fetch data from off-chain systems while safeguarding user privacy and data confidentiality. DECO uses Multi-Party Computation (MPC) to achieve its integrity and confidentiality properties. Town Crier, on the other hand, relies on a Trusted Execution Environment (TEE) for confidential computing. We chose DECO over Town Crier in DARTIC due to its trustless design. Specifically, DECO enables a single prover to extract verifiable statements from a private TLS session with a web server and make them publicly verifiable by all nodes (as detailed in §IV-B). Consequently, the entire network can verify the authenticity of the attested data and trigger on-chain execution.

5

IV. D ECENTRALIZED A NONYMOUS C ROWDSOURCING DARTIC uses a set of cryptographic building blocks on top of IDML and CSML to guarantee anonymous reputation and payments. In the following, we first present these cryptographic primitives; then, the proposed protocols for registration, access, anonymous reputation and payments. A. Cryptographic Building Blocks The main cryptographic building blocks on which the DARTIC system is built are the following: Hash Commitment. A commitment scheme is a cryptographic protocol that allows a party, referred to as the committer, to commit to a chosen value without revealing it, while still being able to prove its validity later on [32]. A hash commitment scheme involves the use of cryptographic hash functions to achieve this goal. Let x be the secret value to commit to, r a trapdoor (randomness or key), and COMM the commitment function. Committing to x involves computing: cm = COMMr (x) = H(x∥r), where H is a cryptographic hash function. Hash commitments are designed to fulfill two security properties: (i) Hiding: Given cm, it should be computationally infeasible to determine the original value x, (ii) Binding: It should be computationally infeasible to find two distinct values x1 and x2 s.t. COMM(x1 ) = COMM(x2 ). Threshold Signature. A threshold signature (TS) [33], [34] is a distributed multi-party signature protocol in which the signing key is split into n shares, with each share held by a different individual or entity. When the threshold is set at t, no group of fewer than t + 1 shares can generate a valid signature on behalf of the group. The protocol for a (t + 1, n) TS scheme involves the following steps: λ • KeyGen(1 ) → (sk, vk, ski , vki ): The system is initialized by generating a secret key sk and a verification key vk. These keys are distributed among n signing members, each receiving a secret key share ski and a corresponding verification key share vki . This process can be executed without relying on a trusted third party using a Distributed Key Generation (DKG) method [35]. • PartSign(m, ski ) → σi : Given the secret key share ski and a message m to be signed, each member computes a partial signature share σi . • VerifyPartSign(m, vki , σi ) → 0/1: This step verifies the validity of a partial signature. Given the message m, the verification key share vki , and the partial signature σi , the function returns 1 if σi is valid; otherwise, it returns 0. • AggSign(σ1 , . . . , σt+1 ) → σ: Once t + 1 valid partial signatures σ1 , . . . , σt+1 are collected, they are combined to produce the final aggregated signature σ. • VerifySign(vk, m, σ) → 0/1: In the final step, the validity of the aggregated signature σ is checked. Given the verification key vk, the message m, and the aggregated signature σ, the function outputs 1 if σ is valid; otherwise, it outputs 0. A threshold signature scheme satisfies the following: (i) Unforgeability: Given any t partial signatures, an adversary is unable to forge a valid, complete signature for a message that has not been signed by the honest participants. (ii) Robustness:

If the adversary controls ≤ t members, the honest participants can still generate the complete signature. zkSNARKs. A zero-knowledge Succinct Non-Interactive Argument of Knowledge (zkSNARKs) is a Non-Interactive ZeroKnowledge (NIZK) scheme [36], wherein the proof itself is a self-contained data block that can be verified without requiring any interaction from the prover. It provides zero-knowledge, soundness, completeness, succinctness, and non-interactivity as key properties [37]. A zkSNARK construction [36] consists of four algorithms (Setup, Gen, Prov, Verif) defined as follows: • The Setup algorithm takes a security parameter λ and generates the public parameters: Setup(1λ ) → pp • The key generator algorithm Gen takes pp and a program C, and generates two publicly available keys: a proving key P K, and a verification key V K; (P K, V K) = Gen(pp, C). These keys are public parameters that need to be generated only once for a given program C. • The proving algorithm Prov takes as input the proving key P K, a public input t, and a private witness w. The algorithm generates a proof π = Prov(P K, t, w) that the prover knows a witness w and that the witness satisfies the program C. • The verification algorithm computes Verif(V K, t, π) which returns true if the proof is correct, and false otherwise. Thus, this function returns true if the prover knows a witness w satisfying C. zkSet Membership via Merkle Trees. This involves proving that an element belongs to a set using the Merkle tree data structure. Formally, given a set S containing n elements and a Merkle tree constructed from the hash values of these elements, the set membership problem is to prove that a specific element x belongs to the set S without revealing any other elements in S [38]. Merkle trees alone do not provide zk property. To achieve this, we combine Merkle trees with zkSNARK constructions [36], [37], ensuring: (i) Correctness: The proof is valid if and only if x truly belongs to S, (ii) ZeroKnowledge: The verifier learns nothing about S or x beyond the validity of the proof, (iii) Succinctness: The proof size and verification time are constant O(1). We define two variants of the zkSet problem to ensure both privacy-preserving access control and reputation binding. Definition 4.1 (zkSet for Access Control): A prover proves knowledge of a secret a s.t. the cryptographic commitment cmA , representing the user’s access credentials A, appears as a leaf in a collision-resistant hash (CRH)-based Merkle tree, ACT ree, whose root is rtA . Definition 4.2 (zkSet for Reputation Binding): A prover proves knowledge of a secret b s.t. the cryptographic commitment cmR , computed based on a reputation score R, appears as a leaf in a CRH-based Merkle tree, RCT ree, whose root is rtR . We detail the integration of these variants in §IV-C and how they are scaled through aggregation and batching in §VI-D. B. Registration & Access The registration process takes place between a user u and the IDML committee. We build a trustless protocol that ensures uniqueness while issuing master credentials Mcred

6

for any valid user u. To this end, we use a decentralized Oracle network to enable the import of credentials from legacy systems. For example, Alice can use her credentials on her Social Security Administration (SSA) account to generate a pre-credential certifying her Social Security Number (SSN) [25]. We extend the DECO protocol [24] with verifiable randomness and zero-knowledge proofs (ZKPs) to preserve user privacy while ensuring decentralization. DECO involves a prover (P ), a verifier (V ), and a TLS channel, enabling P to convince V that private server data satisfies a given predicate. We enhance DECO’s multiparty computation (MPC) with verifiable randomness to guarantee authenticity and integrity, and integrate zero-knowledge proofs (ZKPs) to attest predicate satisfaction without revealing the underlying data. The process involves running a multiparty computation (MPC) protocol, with a user u acting as the prover and attesting to the claim: “the webpage retrieved from the SSA website includes a private string e.g., SSN: 123-456789”. Protocol 1 details the required steps. Register

PROTOCOL 1: U −−−−−−→ IDML {ISC}, DON Setup: IDML CS = {cni } with signing keys {ski }. Result: Issue valid master credentials Mcred for user u. 1. Initialization: User u invokes the contract ISC to register. 2. Random Committee Selection: • DON receives an on-chain event REGISTER. • Then generates a random seed r using a Verifiable Random Function (VRF) [39], producing (r, πr ). • πr is broadcasted and verified by DON and IDML nodes to ensure r is authentic. • The random seed r is used to select k > t+1 committee nodes {cn1 , . . . , cnk }: cni = H i (r) mod n, i = 1, . . . , k. Here, H i (r) denotes applying H iteratively k times. 3. Proof Verification and Partial Signing: • For each cni (i ∈ [1, k]): – u executes Algo.1 to prove the claim Φ with cni as the verifier. – cni verifies the received proof Π – If valid, cni generates a partial ECDSA signature σi = Sigski (Φ) and sends it to DON 4. Signature Aggregation: • DON aggregates the partial signatures {σi } to produce the final committee signature σcred . 5. On-Chain Verification: • DON invokes the verifyClaim function within ISC using σcred to validate the claim publicly on-chain

■ ■

Algorithm 1: Proving Claim via DECO [24] and ZKPs Data: Website WS, claim Φ, Verifier cni Result: Zero-Knowledge Proof Π of claim 1 begin 2 Prover u and verifier cni execute the DECO three-party handshake with WS, establishing secret-shared TLS session keys (kP , kV ) 3 u retrieves encrypted data D from WS via the DECO query execution protocol 4 u commits to the TLS transcript and obtains verifier key share 5 u computes commitment COMM(D) 6 u formulates the claim Φ(D) = ”SSN matches criteria” 7 u generates ZKP Π proving that: • D originates from an authentic TLS session • COMM(D) corresponds to the committed transcript • Φ(D) holds u sends (Φ, Π) to verifier cni

u set, a credential is issued. Finally, (Mpku , pkctx ) is added to Grantedctx . To manage access tokens efficiently, we use a CRH-based Merkle tree (with root rtA ) called ACT ree. The tree stores all the users’ access commitments as leaves. hence, minting a new access token AT means adding a new valid leaf cmA to ACT ree. This is done following Protocol 2. MintAT

PROTOCOL 2: U −−−−→ IDML {ASC} Data: ACT ree with root rtA , contains all user access commitments. ■ Result: Generate and Mint Access Token. 1. User u generate key pair (pk, sk) public and secret key. 2. Compute access commitment in two steps: u i) Sample a random r and set: cmu = COMMr (skctx ) ii) Sample r′ and set: cmA = COMMr′ (cmu ||pk) u ′ 3. Define access token: AT = (skctx , r, r , cmA ) 4. Create transaction: TXAM = (pk, cmu , cmA ) 5. Invoke ISC: submit TXAM to the IDML u - Only accept if pkctx is known to the committee 6. Update ACT ree with new cmA and emit MINTAT event 7. Synchronization: Upon receipt of MINTAT event, DON updates ACT ree on CSML with new leaf cmA

■

The protocol ensures that master credentials are never used in interactions, preventing any linkage to the user’s real identity. Furthermore, contextual credentials are used exclusively within the IDML and remain cryptographically concealed when handled by the CSML. C. Anonymous Reputation

If the σcred is valid, the master public key Mpku of the user is whitelisted. u then can post another set of claims to IDML to get access to CSML using context-based credentials [25]. To obtain a new credential for the ctx context (e.g., “crowdsensing”), u must submit to the committee (pkctx , Mcred , Φuctx ), a new identifier pkctx to be used in the ctx context, master credentials and a set of pre-credentials with the claims Φuctx required by ctx (e.g., location = “Paris city”). The IDML via the contract ISC upholds a set of Grantedctx identifiers denoting those that have already obtained a credential within this specific context. If Mpku of Mcred is not part of this

Now that we have described the registration process, we will move on to anonymous reputation, which consists of four key steps as depicted in Fig.2. Step 1. Mint Initial Reputation Token: In this initial step, a reputation token is minted that is cryptographically linked to the user’s contextual credentials. This process conceals the u user’s digital identity (i.e., pkctx ) while granting access to the CSML. To do so, users must spend their access tokens and mint their initial reputation token RT0 following Protocol 3. This results in a new valid leaf being inserted into RCT ree, containing a commitment to the initial reputation score R0 .

7

[Step 1: Spend AT & Mint Init RT] Generate new keys (apk0,ask0) Form Token RT0 and prove AT Submit TXRM (cmR0, proof ...) to CSML, insert cmR0 to RCTree

[Step 4: Mint RT after k use] Form new Token RTi+k Submit TXRM (cmRi+k, ...) with the same pseudo apki+1

[Step 2: Spend or Use RT] SPEND: Form new RTi+1 with new apki+1 prove RTi, insert cmRi+1 to RCTree USE: NO new token, prove RTi validity, show score Ri+1= Ri with new apki+1

[Step 3: Reputation Update] Publish a new task (Requesters) Subscribe to task (Workers) DON evaluates interaction CSML updates Ri+1 with PW-Mean

Fig. 2: DARTIC’s anonymous reputation lifecycle. Users start by (Step 1) proving the ownership of a valid AT and minting an initial RT0 . In (Step 2), reputation tokens are spent or used to interact within the CSML, generating unlinkable pseudonyms for each transaction. In (Step 3), oracle nodes evaluate interactions and securely update reputations on-chain via a threshold signature. Finally, in (Step 4), after k ≥ 1 updates, users can mint new tokens (RTi+k ) to restore anonymity while carrying forward accumulated reputation.

interact with any other user v on the CSML by submitting transactions. Within DARTIC, users’ reputation scores are tied to their most recent reputation commitment cmR . Thus, for interaction, users must reveal this nested commitment to disclose their reputation scores. Since only the user possessing the secret r′ can show it, there is no risk of forgery. Spend A Reputation Token. To adopt a new pseudonym in future interactions—denoted apk i+1 , distinct from the current apk i —a user u on CSML spends his reputation token. This is done by submitting an RT spending transaction, TXRS , as defined in Protocol 4. This transaction enables u to generate a new token RTi+1 of identical value (Ri+1 = Ri ) to the current one. The user must attach a zk proof πRS to prove the validity of both the old and new token, and the fact that a valid commitment cmR exists as a leaf in RCT ree. SpendRT

PROTOCOL 4: U −−−−−→ CSML {RSC} Data: old key pair (apk, ask)i , old reputation token RTi := (apk, R, s, r1 , r2 , cmR )i , and rtR . i i+1 ■ Result: Spend old RT and Mint new RT . i+1 a. Produce a new token RT : i+1 1. User u generates a new key pair (apk, ask) i+1 2. User u samples serial number randomness s i+1 i+1 3. Set cmp := [COMMr1 (apk||s)] with random r1i+1 i+1 i+1 4. Set cmR := [COMMr2 (R||cmp )] with random r2i+1 i+1 5. Form RT := (apk, R, s, r1 , r2 , cmR )i+1 b. Generate zk proof πRS to spend old token RTi that: 1. Verify well-formedness of tokens: i i i • Check cmp == [COMMr1 (apk||s)] and cmR == i [COMMr2 (R||cmp )] i+1 • Similarly, check cmp and cmi+1 R 2. Verify key matching: i i+1 • apk == PRFaski (0) and apk == PRFaski+1 (0) i i 3. Verify correct serial number: Sn == PRFaski (s ) i 4. Check cmR is a leaf in RCT ree with root rtR i+1 5. Check reputation values match: R == Ri i+1 i c. Define TXRS := (rtR , Sn , cmR , πR ) d. Invoke RSC: submit TXRS to the CSML. - Reject if Sni appears in a prior transaction or πRS is invalid. ■

To provide targets for new tokens, we use addresses: each user u generates an address key pair (apk, ask), the address public and private key, respectively. The token of u contains the value apk and can only be used with the knowledge of ask. A key pair (apk, ask) is sampled by choosing a random seed ask and setting apk := PRFask (0) using a PseudoRandom Function. To ensure forward reputation binding, the user must also sample a random serial number, Sn , for each new reputation token. This serial number is revealed when the token is used. SpendAT

PROTOCOL 3: U −−−−−→ CSML {ASC, RSC} Data: AT, ACT ree with root rtA , initial reputation R0 Result: Spend AT and Mint Initial RT0 . 0 1. User u generates a new key pair (apk, ask) 0 0 0 2. User samples a random s and set: Sn := [PRFask (s)] 0 0 3. User samples two random r1 and r2 and commits to the tuple (apk, R, s)0 in two steps: i) cm0p := [COMMr1 (apk||s)]0 , ii) cm0R := [COMMr2 (R||cmp )]0 0 0 4. This results in: RT := (apk, R, s, r1 , r2 , cmR ) 5. User u produces a zk proof πAS for the NP statement: “I know a secret r′ s.t. COMMr′ (cmu ||pk) appears as a leaf in a CRH-based Merkle Tree ACT ree whose root is rtA ” 0 0 0 6. Then defines: TXAS := (R , cmp , r2 , cmR , πAS ) 7. Invoke ASC: submit TXAS to the CSML. - Accept only if πAS is valid and cm0R is correct. 0 8. Update RCT ree with new leaf cmR .

■ ■

The anonymity of the user is achieved because the proof πAS is zero-knowledge: while cmu and pk are revealed, no information about r′ is revealed, and finding which of the many commitments in ACT ree corresponds to TXAS is equivalent to inverting f (r′ ) := COMMr′ (X), which is computationally infeasible [32]. Step 2. Reputation Token Spend/Use: So far, user u has minted his initial reputation token RT0 . Therefore, u can

Use A Reputation Token. Protocol 5 details how to use RTi : UseRT

PROTOCOL 5: U −−−−→ CSML {RSC} i i Data: RCT ree with root rtR , Sni , cmi+1 R , RT , ask i Result: Use current RT . i+1 1. User u generates a new key pair (apk, ask) i 2. Generate zk proof πRU to use RT that: i) Verify RTi : cmip == [COMMr1 (apk||s)]i and cmiR == [COMMr2 (R||cmp )]i

■ ■

ii) Check apki == PRFaski (0) and Sni == PRFaski (si ) iii) cmiR is in RCT ree with root rtR i i 3. Create transaction TXRU = (rtR , Sn , R , πRU ) 4. Invoke RSC: submit TXRU to CSML. - Accept only if πRU is valid and Sni does not appear in a prior TX. If so, add (apki+1 , Ri+1 = Ri ) to V alid.

8

This allows u to show the most recent reputation Ri and link it to a new pseudo apk i+1 (without minting a new token) by proving RTi correctness and a valid cmiR is in RCT ree. A successful TXRU allows u to interact with other users. The corresponding apk i+1 is then added to V alid, a whitelist that maintains the set of authorized application public keys together with their associated reputation values. The user’s identity is u protected, as pkctx remains hidden. The access token spending transaction, TXAS , is submitted under a pseudonym apk i ̸= u pkctx . Likewise, TXRS and TXRU transactions are posted with a new pseudonym apk i+1 ̸= apk i . The three pseudonyms are mutually unlinkable as both transactions reveal nothing but a random Sni , the Merkle root rtR , and a zk proof. The completeness, soundness and zk properties are formally established in Appendix B. Step 3. Reputation Update: This step is automated through DON integration. First, the network retrieves the relevant off-chain data and derives the evaluation metrics (via an oracle function). After collective verification and attestation, the DON runs Algo.2 which invokes the RSC to update the reputations of u and v under their pseudonyms apkiu and apkiv . The signature here is instantiated using a standard (t + 1, n) ECDSA scheme [33], [34], ensuring both interoperability and strong threshold security. Concretely, the oracle nodes execute a DKG [35] protocol to jointly generate shares of a single ECDSA private key without relying on any trusted third party. During reputation updates, each oracle produces a partial signature on the task identifier and associated metrics, which are then verified and securely aggregated into a final signature σorc once at least t + 1 valid shares are collected. Importantly, the resulting aggregated signature is indistinguishable from a standard ECDSA signature and can be verified using the corresponding public key by the smart contract. This makes the protocol fully compatible with well-established constructions (e.g., GG18 [33], GG20 [34]), which provide security against up to t colluding adversaries. The complete reputation update process is detailed next. Interaction Participation: Protocol 6 outlines how a requester u and a worker v share and participate in a task. PublishTask

PROTOCOL 6: U −−−−−−−−−−→ CSML {BSC} SubscribeTask

u v Data: taskID, reward, skctx for u and skctx for v Result: Publish/Subscribe to a Task u u 1. The user u computes H := COMM(taskID||skctx ) u 2. The user u generates a zkSNARK proof πI for the following NP statement: “Given the task identifier taskID, I know a secret u skctx , and ATu s.t. H u is computed correctly and u shares the same skctx with ATu ”. u u 3. Invoke BSC: TXnewTask := (taskID, reward, H , πI ). 4. Similar to u, user v runs steps 1 and 2. Then, v submits TXsubToTask := (taskID, H v , πIv ) to the CSML. u 5. TXnewTask is rejected if πI is invalid; and TXsubToTask is rejected if H v == H u or the proof πIv is invalid.

■ ■

Suppose an interaction where a worker v wants to perform a task (i.e., provide a service) for a requester u. The requester u must first publish the task. To do so, u must use the current

Algorithm 2: Distributed Reputation Token Update. Data: taskID, Threshold t, RSC address, requester, workers, metrics Result: Reputation tokens updated for requester and workers. ▷ Any oracle node Upon receipt of TASK S TATUS E VENT(taskID) do 3 if GET S TATUS(taskID) == ”Valid” then 4 Broadcast UPDATE RTR EQUEST(taskID, requester, workers, metrics) to all oracles

1 2

▷ The aggregator is the node that distributed the request Upon receipt of UPDATE RTR EQUEST(taskID, requester, workers, metrics) do 7 if VALIDATE R EQUEST(taskID) then 8 σi ← GENERATE PARTIAL S IGNATURE(taskID) 9 Send PARTIAL S IGNATURE(σi ) to aggregator

5 6

10 11

else Send VALIDATION FAILED to aggregator

Upon receipt of PARTIAL S IGNATURE(σi ) from oracles do S ← S ∪ {σi } 14 if |S| ≥ t + 1 then 15 σorc ← COMBINE S IGNATURES(S) 16 Broadcast (σorc , taskID) to oracles 17 Call RSC. UPDATE RT(requester, workers, metrics)

12

13

▷ On-chain verification and RT update Function executeUpdateRT(σorc , taskID, requester, workers, metrics): 20 if VERIFY W ITH P UBLIC K EY(σ, taskID) then UPDATE RT(requester, workers, metrics)

18 19

reputation token (Step 2). Then u can share the new task by posting the transaction TXnewTask := (taskID, reward, ...), taskID can be the content identifier (CID) of the task description on IPFS [40]. Now, any worker v who wants to perform this task must subscribe to the task by posting a TXsubToTask transaction. Both u and v must provide zkSNARK proof that they do not share the same access token. This condition is necessary for our construction because it prevents selfpromotion attacks. Interaction Evaluation: The evaluation of interactions must strictly preserve privacy: the reputation model neither relies on nor exposes workers’ historical or sensitive data. Each interaction is assigned a weight defined as:    W = κ · ω0 + ωd Fd + ωa Fa + ωst Cst   f (1) κ, ω0 , ωd , ωa , ωst ∈ [0, 1],   ω0 + ωd + ωa + ωst = 1, where κ is a scaling factor, ω0 is the baseline weight, and ωd and ωa capture the normalized duration d and amount a, a d , 1), Fa = min( amax , 1) respectively: Fd = min( dmax The optional term ωst Cst accounts for spatiotemporal context. By design, all contributions are capped within [0, 1], to mitigate collusion and Sybil-style inflation attacks. Here, dmax denotes the maximum meaningful interaction duration (e.g., 24 hours or a domain-specific bound), and amax is the maximum meaningful amount (e.g., the highest transaction value). Interactions with negligible duration or value (e.g., d = 0.1 h, a = 1 unit) yield near-zero Fd and Fa , ensuring that repeated micro-interactions cannot be exploited.

9

The worker v contribution is evaluated by combining rater feedback with auxiliary contextual metrics: X X Tv = αj Pjv , αj , Pjv ∈ [0, 1], αj = 1, (2) where each parameter Pjv (e.g., feedback score, task-specific quality indicator) is weighted by its importance coefficient αj . Reputation Update: Global reputation scores evolve through a piecewise-weighted mean (PW-Mean) update rule: ( (1 − ψWf )Rv,i + ψWf T v,i , T v,i ≥ Tθ , v,i+1 R = (3) (1 − ξWf )Rv,i + ξWf T v,i , T v,i < Tθ , where Rv,i is the reputation of worker v after its i-th interaction, T v,i is the corresponding trust value Eq. (2), Tθ is a trust threshold (e.g., Tθ = T ), and Wf is the interaction weight Eq. (1). The coefficients ψ and ξ (ξ > ψ) control the asymmetry between positive and negative updates. This asymmetry penalizes malicious or low-quality interactions more than it rewards positive ones, making reputation harder to build than to lose. Eq. (3) corresponds to a piecewise exponential moving average (EMA [41]), which is a contraction mapping for 0 < γWf < 1, where γ ∈ {ψ, ξ}. This guarantees stability and exponential convergence toward the underlying trust value, as formally shown in Appendix A. Larger values of γ increase responsiveness but may amplify noise, whereas smaller values improve robustness at the cost of slower convergence. The asymmetry constraint ξ > ψ enforces a security-oriented design in which negative interactions have a stronger impact than positive ones, limiting reputation inflation and improving resilience against collusion and opportunistic attacks. The trust threshold Tθ defines the minimum acceptable trust level. In practice, these parameters can be selected based on security requirements or dynamically adapted. For instance, the update coefficients can be dynamically adjusted as functions of the current reputation level or global system conditions, e.g., ψi = ψ0 Rv,i ,

ξi = ξ0 (1 − Rv,i ),

(4)

which increases penalties for low-reputation workers while progressively stabilizing trusted ones. Similarly, the threshold Tθ can be defined using population statistics (e.g., mean or percentile of trust values) to reflect the current system state. This adaptivity preserves the convergence guarantees while improving robustness and generality across heterogeneous scenarios. Appendix A provides concrete instantiations of Eq. (2) and formally proves that the proposed update rule in Eq.(3) defines a bounded and stable dynamical system and guarantees exponential convergence toward the underlying trust level (Lemma 1–5 and Theorem 1). Step 4. Mint a new Reputation Token: Now, if, after some interactions k, u wants to use a different pseudonym to regain anonymity, let us call it apk i+k , u must mint a new token using apk i and the most recent reputation Ri+k . This is done following Protocol 7. If TXRM passes, the address public key apk i+1 (not apk i+k ) is removed from the list V alid. The user cannot use it again and must spend or use the freshly minted token RTi+k for future interactions.

MintRT

PROTOCOL 7: U −−−−→ CSML {RSC} Data: Address Key pair (apk, ask)i Result: Mint a new RTi+k with Ri+k = Ri . i+k 1. User u generates a new key pair (apk, ask) i+k 2. Sample s (serial number randomness) i+k 3. Set cmp := [COMMr1 (apk ∥ s)]i+k with random r1i+k i+k i+k with random r2i+k 4. Set cmR := [COMMr2 (R ∥ cmp )] i+k i+k 5. Form RT := (apk, R, s, r1 , r2 , cmR ) i+k 6. Form TXRM := (R, cmp , r2 , cmR ) 7. Invoke RSC: Submit TXRM to the CSML. - Accept only if apki ∈ V alid and cmi+k is correct. R

■ ■

D. Anonymous Payment Unlike traditional anonymous payment systems, which raise concerns about their use in money-laundering activities by cybercriminals and malicious actors, we use dynamic whitelisting via a smart contract to guarantee compliance. This means that only registered and authorized addresses can make payments on the CSML. To this end, we adapt the Tornado Cash protocol [42] to our permissioned setting. Specifically, an access control smart contract (ASC) maintains the set of valid accounts. Only addresses apk ∈ V alid are permitted to interact with the deposit smart contract (DSC). To deposit an amount D, a user (e.g., a requester) generates and signs a transaction TXdeposit with the private key associated with their current reputation token RTi (i.e., apk i ∈ V alid ). To form TXdeposit , the user first computes a commitment cmD = COMMr (s ∥ D), by hashing a random secret s concatenated with the amount D using a trapdoor r. The signed transaction TXdeposit := (taskID, D, cmD ) is then submitted to CSML, which inserts cmD into a Merkle tree of deposit commitments DCT ree and locks the amount D in DSC. To prevent double-spending, each secret s is deterministically mapped to a nullifier ns = NULL(s) that is revealed at withdrawal. The funds D are transferred to the other party (e.g., workers) as payment after a successful interaction by invoking the withdraw function through a threshold signature scheme similar to the one detailed in Algo. 2. In case of an unsuccessful interaction (e.g., timeout or invalid check), the requester can reclaim the funds locked in DSC by withdrawing them to any valid address apk. To do so, the requester must produce a zk proof πD for the following: “I know a valid opening (s, r, D) s.t. cmD = COMMr (s ∥ D) appears as a leaf in a CRH-based Merkle Tree DCT ree whose root is rtD ”. The proof πD is verified by DSC as part of the TXwithdraw . If πD is valid, the contract transfers the corresponding amount D to the new account apk. The contract maintains a record of valid accounts and used nullifiers; therefore, if the target address apk ∈ / V alid or the nullifier ns has already been used, the withdrawal request is denied.

10

V. T HEORETICAL A NALYSIS This section examines the security and privacy properties of DARTIC as defined in §III-A. While network activities such as posting transactions may reveal identifiers like IP addresses, and an anonymous network (e.g., Tor [43]) is recommended, securing network activity is beyond the scope of this analysis. Sybil resistance: In DARTIC, each legitimate user is granted only one valid credential for each specific context. Specifically, the IDML committee maintains a set of Grantedctx identifiers, representing those already having credentials within that context. If Mpku in Mcred is not part of this set, a credential is granted; otherwise, no additional credential is issued for that user. This ensures that a user cannot generate and spend more than one valid access token per context, effectively mitigating Sybil attacks. • Collusion resistance: The proposed registration protocol mitigates collusion attacks through the combined use of verifiable randomness, distributed signing, and on-chain verification. Together, these mechanisms ensure the integrity and security of the reputation system. - Randomness. This ensures that the selection of k > t + 1 committee nodes (cn1 , . . . , cnk ) for verifying a user’s claim is unpredictable. VRF [39] is used to generate a secure and verifiable random seed r. Any entity, such as IDML committee nodes, oracle nodes, or smart contracts, can verify the proof πr using the VRF public key. Using r as a seed, k committee nodes are selected via a secure hash function. This tamper-proof process ensures the prover and verifier cannot manipulate node selection, and collusion requires compromising a significant and randomly chosen fraction of the network, which is computationally infeasible. - Distributed Signing and Threshold Security. Distributed signing requires independent validation from multiple committee nodes. During credential issuance (§IV-B), each node verifies the proof Π and, if valid, generates a partial signature σi = Sigski (Φ). The DON aggregates these partial signatures into a final signature σcred only if at least t + 1 valid signatures are collected. Therefore, even if some nodes collude with the prover, they cannot forge the final signature unless t + 1 nodes are compromised. - On-Chain Verification. On-chain verification guarantees transparency and builds trust by publicly verifying aggregated signatures through the ISC and RSC. • User Privacy: Generating a pre-credential for a claim within the Oracle protocol does not disclose any information about the user. Furthermore, given the commitment’s hiding property and the privacy guarantees provided by MPC via ZKPs in DECO [24], there is no opportunity for an attacker to gain knowledge about the user during the issuance process. In addition, since no personal information is used when evaluating interaction within CSML, there is no risk of deanonymization or leakage of workers’ identity information. • Unlinkability: We analyze this property considering the system’s cryptographic building blocks (§IV-A): hash commitments, zkSNARKs, and zkSet membership proofs. - User–Pseudo unlinkability. Each user u generates a unique key pair (sku , pku ) when minting a token AT or RT.

•

The public key pku is a pseudonym in the system. The zkSNARK Prov algorithm allow u to spend a token (AT or RT) without revealing the corresponding private key sku or linking the current pseudonym to any previous pseudonym. Formally, following Definitions 4.1 and 4.2: (i) to spend an AT with cmA = COMMr (sku ), user u provides a zkSNARK proof that cmA exists as a leaf in ACT ree without revealing sku , r or any other leaves. (ii) Similarly, to spend an RT, cmiR is proven to exist in RCT ree. Since zkSNARKs provide zero-knowledge, an adversary observing the transaction cannot determine which user owns a given pseudonym. Furthermore, the use of fresh key pairs for each token issuance ensures that pseudonyms do not reveal identity correlations across multiple transactions. - Pseudo–Pseudo unlinkability. Unlinkability between different pseudonyms of the same user is achieved as follows: (i) Each AT or RT issuance generates a new key pair and associated commitment. These commitments are inserted into their respective Merkle trees, ACT ree or RCT ree, (ii) When spending a token, the zkSet proof proves membership in the tree but does not reveal linkage. Because the Merkle proofs are combined with zkSNARKs (§IV-A), an adversary cannot distinguish whether two different pseudonyms belong to the same user. The adversary’s advantage is bounded by ϵ, which is negligible under standard cryptographic assumptions (collision-resistance of hash functions and soundness of zkSNARKs). • Accountability: In DARTIC, accountability combines reputation management and AT binding: (i) misbehavior sharply reduces a user’s reputation, limiting influence and access; (ii) users below a reputation threshold are sanctioned (i.e., removed from V alid), preventing interactions under their current pseudonym; (iii) re-entry requires minting a new AT, constrained by the one-AT-per-context rule (AT binding), preventing circumvention of sanctions. • Reputation Binding: This is based on the unforgeability of the ECDSA signatures used to create contextual credentials and submit ATs. The latter’s security is based on the assumption that the Elliptic Curve Discrete Logarithm Problem (ECDLP) is hard to solve [33], [34]. Moreover, a prover in our system cannot change the committed value once a commitment is made, which is crucial in proving knowledge of a fixed secret without altering it later. Under our zkSNARK constructions, an adversary cannot falsely generate proofs for different values while committing to the same hash. • Forward Reputation Binding: DARTIC satisfies this property if the signature scheme prevents forgery, the commitment scheme maintains the hiding and binding properties, and the zkSNARK scheme ensures soundness. These combined properties ensure the new reputation score is accurate, private (if not shown), and consistently linked to the entity (access token) it represents. A formal analysis of how our zkSet constructions algebraically enforces these constraints—guaranteeing soundness, completeness, and zeroknowledge—is provided in Appendix B.

11

VI. E VALUATION AND R ESULTS In this section, we present an experimental evaluation of DARTIC to assess its efficiency, scalability, and resilience. Additional experiments that compare the proposed PW-Mean model with baseline models and show the optimal RT reuse window are provided in Appendix C. A. Experimental Setup We developed a proof of concept for DARTIC and the proposed protocols. The circuits are implemented using the circom domain-specific language (DSL) and the circomlib library1 , while snarkjs2 is used to compile the circuits and perform the powers of tau ceremony for the trusted setup [44]. The smart contracts for DARTIC are coded in Solidity. For ACT ree, RCT ree, and DCT ree, we implement a 20level Merkle tree using MiMCSponge3 , a lightweight hash function optimized for ZKPs. Each tree operation requires 40 MiMCSponge calls—one hash per level, with two calls per hash to compute the node ( left) and its sibling ( right). Datasets and models. To evaluate the effectiveness and robustness of the proposed reputation model and the PWMean aggregation method, we conducted experiments that simulate federated learning and crowdsensing scenarios. We select datasets to serve as realistic sources of heterogeneous, noisy, and potentially adversarial interaction outcomes, rather than as benchmarks for learning performance. Specifically: (i) For federated learning tasks, we use MNIST [45] and CIFAR-10 [46] to train a simple CNN and a ResNet-18 model, respectively. These datasets generate controlled yet diverse model updates, allowing us to emulate honest, low-quality, and malicious contributions. (ii) For crowdsensing tasks, we use the OpenSense Zurich dataset [47], which provides realistic environmental sensing traces. The dataset allows us to simulate varying quality of service, data noise, and strategic misreporting by participants. (iii) Interaction outcomes from all datasets are mapped to quality signals, which serve as inputs to the PW-Mean reputation update function. Thus, these datasets are used as behavioral generators to model service reliability and adversarial dynamics, consistent with previous work on trust and quality evaluation [4], [19], [20]. Environment. Experiments are conducted on a cluster of two HPE ProLiant XL225n Gen10 Plus servers. Each server is equipped with dual AMD EPYC 7713 64-core 2.0 GHz processors and 2 × 256 GB of RAM. Federated learning tasks are executed on a GPU card “NVIDIA A6000”. B. Execution Time We evaluate the zkSNARK constructions in DARTIC using two proving systems: Groth16 [36] and PlonK [37]. Groth16 is a circuit-specific SNARK that requires a structured reference string (SRS) per circuit but offers short constant-size proofs and fast verification. Conversely, PlonK is a universal SNARK scheme with a single updatable SRS for all circuits, albeit with higher proof generation costs and longer call data.

TABLE III: Execution time (s) of individual zkSNARK proofs Groth16 [36] vs. PlonK [37] proving systems. Proof πAS πRS πI πD

System Groth16 PlonK Groth16 PlonK Groth16 PlonK Groth16 PlonK

Setup 150±5 90±5 150±5 90±5 30±5 15±5 150±5 90±5

Prove 2.40±0.10 67.00±0.5 2.90±0.10 79.5±0.50 0.48±0.05 3.40±0.10 2.30±0.10 65.0±0.50

Verify* Call Data size 0.73±0.05 705B 0.76±0.05 1750B 0.95±0.10 705B 0.93±0.10 1750B 0.64±0.05 705B 0.67±0.05 1750B 0.71±0.05 705B 0.73±0.05 1750B

*on-chain verification time

Table III presents benchmark results for proof generation and verification times across four circuits: πAS (access token), πRS (reputation token), πI (interaction proof), and πD (deposit proof). For each proof, we report timings under both Groth16 and PlonK. On average, Groth16 enables efficient proving within 0.50–2.90s and verifying within 0.60–0.95s per proof, while PlonK requires 3.40s to over 80s for proof generation, depending on circuit complexity. Regarding the trusted setup, Groth16 requires circuitspecific SRS generation involving heavy pairing operations. While this introduces setup overhead, DARTIC uses a fixed and limited number of circuits (four), making Groth16’s percircuit setup a one-time cost that does not impede scalability. In contrast, PlonK decouples setup from circuit structure, relying on polynomial commitment schemes that facilitate faster universal SRS generation. However, due to its significantly higher proving time and proof size (1.75KB vs. 705B), we find Groth16 more favorable for our current architecture. C. L1 Performance We evaluate DARTIC on-chain performance on a singlelayered (L1) blockchain using Caliper4 . To this end, we deploy and benchmark our smart contracts on a local Hyperledger Besu5 network comprising 15 validators using Quorum-BFT as the consensus protocol. The experiments involve using two workloads (1024 and 2048 workers) while altering the TX sending rate (ranging from 10 to 450 TPS) using a consistent network configuration (standard block time =1s and 12 validators) for the main operations. The average values of latency and throughput are shown in Fig.3 and the respective gas costs are presented in Fig.4. The system throughput scales proportionally with the transaction sending rate until it approaches its saturation point. For instance, TXupRep reaches a peak of 255 TPS at a send rate of 350 TPS, after which performance begins to degrade. The system maintains a low end-to-end latency (below 3s) for TXupRep as long as the workload remains within this optimal range, indicating efficient handling before overload conditions occur. The other transaction types exhibit a similar pattern but achieve lower peak throughput due to their higher computational complexity. In particular, TXAM , TXRM , and TXdeposit are more resource-intensive because they require inserting the cmA , cmR , and cmD commitments into the respective

1 https://github.com/iden3/circomlib 2 https://github.com/iden3/snarkjs

4 https://github.com/hyperledger/caliper-benchmarks

3 https://github.com/iden3/circomlib/blob/master/circuits/mimcsponge.circom

5 https://besu.hyperledger.org

12

20 20

30

50

100

Send Rate (TPS)

150

200

300

60

7.5

40

5.0

20

2.5 0.0

10

20

(a) mintAT (TXAM )

Throughput (1024 workers) Throughput (2048 workers)

6 4 2

100

150

200

250

300

Send Rate (TPS)

350

100

150

200

300

40 20 0

400

450

10 8 6 4 2 0

10

(d) updateRT (TXupRep )

20

30

Latency (1024 workers) Latency (2048 workers)

50

100

Send Rate (TPS)

150

200

10 8 6 4 2

10

50

100

150

200

Send Rate (TPS)

250

300

400

(c) useRT (TXRU )

300

Throughput (1024 workers) Throughput (2048 workers)

80

Latency (s) Throughput (TPS)

Latency (1024 workers) Latency (2048 workers) 8

50

50

Send Rate (TPS)

Latency (1024 workers) Latency (2048 workers)

60

(b) mintRT (TXRM )

Latency (s) Throughput (TPS)

Throughput (TPS)

Throughput (1024 workers) Throughput (2048 workers) 250 200 150 100 50 0

30

0

Throughput (1024 workers) Throughput (2048 workers)

80

60

60

40

40

20

20

0

0

(e) deposit (TXdeposit )

Latency (1024 workers) Latency (2048 workers)

12 10 8 6 4 2

Latency (s)

10

0

10.0

Latency (s)

40

Latency (1024 workers) Latency (2048 workers)

Latency (s)

Throughput (1024 workers) Throughput (2048 workers)

Throughput (TPS)

Latency (1024 workers) Latency (2048 workers)

Latency (s) Throughput (TPS)

Throughput (TPS)

Throughput (1024 workers) Throughput (2048 workers) 12.5 10.0 7.5 5.0 2.5 0.0

10

50

100

150

200

Send Rate (TPS)

250

300

400

(f) withdraw (TXwithdraw )

Fig. 3: Latency and Throughput of DARTIC.

2.5

1e6

$1.64

$0.17

$6.45

$4.95

$1.61

mi ntA T de po sit sp en dA wit T hd raw mi ntR sp T en dR T us eR T up da teR T

C AS

C RS

C

0.0

$1.50

0.5

$4.73

$4.17

$4.85

$12.80

$10.47

DS

1.0

$9.97

1.5

ISC

Gas Used

2.0

Fig. 4: Deployment and invocation gas costs. CostUSD = −9 gasused × gasgwei × ETHUSD price . price × 10 TABLE IV: Comparison of scaling techniques: Baseline (Groth16) vs. Proof aggregation (SnarkPack) vs. L2 batching. Metric Groth16 SnarkPack zkRollups Verifier Calls n 1 1 (batch n) Proof Size (Call Data) n · 705B ∼800–1000B ∼1–2KB total Verification Time n · 700–950ms ∼1.0–1.3s ∼1.5–2.0s Proving Time tprov per proof tprov + δ1 tprov + δ2 Gas Cost n·G ∼1.3G ≪ G per tx Scalability Low (n on-chain) Moderate (100s) High (1000s) Privacy Guarantee Maintained Maintained Maintained

tprov Parallel client-side proving. δ2 the additional operator-side batching overhead. “Maintained” client-side proving.

ACT ree, RCT ree, and DCT ree Merkle structures. This involves recalculating the Merkle root by recomputing all hash values along the path from the newly added leaf to the root, which introduces additional overhead. L1 results confirm the framework is practical for small to medium (up to 2048 active workers) platforms, though DARTIC performance can be boosted via scaling mechanisms. The next section shows how these address L1’s inherent limits. D. Scalability 1. Beyond individual proofs. While Groth16 is efficient for individual statements, large-scale deployment of

DARTIC—with potentially thousands of token validations per epoch—demands scalable verification. To this end, we investigate proof aggregation and L2 batching via two techniques: SnarkPack [48] and zkRollups [49]. Table IV compares these. SnarkPack [48] aggregates multiple proofs into a single succinct proof. This is done off-chain with Groth16 compatibility. The aggregated verifier runs only once, with slightly increased verification time (∼1.3s for up to 100s proofs) and reduced calldata size. This results in a reduced gas cost (87%, n = 10), which is important for use cases where a user (i.e., an aggregator) submits multiple proofs in a single session. zkRollups [49] batch multiple transactions into a single proof using PlonK [37]. Here, proving occurs in two layers: Client-side proving: Each user independently generates a Groth16 proof of their transaction locally, incurring a proving time tprov per transaction. This step is fully parallelized and distributed across users. • Operator batch proving: The zkRollup operator aggregates the transaction state transitions into a single succinct proof using an efficient PlonK, incurring an additional overhead δ2 . This overhead is amortized over the entire batch. •

Although the aggregation time remains comparable to or slightly higher than the baseline, parallelizing user proofs and amortizing the batch proving overhead with zkRollups drastically reduces the wall-clock. On the verification side, zkRollups require only a single on-chain verifier call, regardless of batch size. While the total verification time (∼1.5–2.0s) is slightly higher than SnarkPack, it remains constant (1 proof per batch) with respect to n. This efficiency also translates into significantly lower gas costs—well below G. 2. Impact of Aggregation. We evaluate DARTIC with and without proof aggregation over 64–1024 workers, reporting proving and verification times of πRS (SpendRT), shown in Fig. 5. On the proving side, parallel execution across 64 workers exhibits near-linear scalability, with runtimes ranging from 3.2s (64-batch) to 47.5s (1024-batch). With aggregation, the same execution introduces only marginal overhead, primarily due to the individual proof checks (< 0.112s) and the

13

40 30

Prove Prove (Agg.) Verify (Off-chain) Verify (Agg. Off-chain) Verify (On-chain) Verify (Agg. On-chain)

Total Verification Time (s)

Total Proving Time (s)

50

8 6 4

20

2

10 64

128

256

512

0

1024

Fig. 5: Proving and verification times of spendRT vs. number of workers. L1, 64 calls L2×10, 64 calls

L1, 512 calls L2×10, 512 calls

L1, 1024 calls L2×10, 1024 calls

teR T da up

eR T us

dR T en sp

mi ntR T

raw hd wit

dA T en sp

po sit de

mi ntA T

Total Gas (×10^6)

1200 1000 800 600 400 200 0

Fig. 6: Total Gas Cost: L1 vs L2 (L2×10 for visibility).

TABLE V: On-Chain Cost and E2E Latency Comparison. Cost (Wei) = Gas × 5 × 109 . System AVeCQ [20] (Image) AVeCQ [20] (Review) Duan et al. [19] DARTIC (no agg.) DARTIC (no agg.) DARTIC (64 proofs) DARTIC (64 proofs)

Workers 39 128 128 39 128 39 128

E2E Latency <8mins* <18mins* 30mins* <3mins <5mins <2mins <2mins

On-Chain Cost <19 MWei 55 MWei >416 MWei <91 MWei <263 MWei <9 MWei <26 MWei

* Denotes extrapolated values based on the reported results.

function ⌈·⌉ accounts for partially filled aggregated calls. L1 total gas cost scales linearly with the total number of calls: Gtotal,L1 = #total calls · GL1

(6)

Fig. 6 summarizes the results with detailed gas values provided in Appendix C Table I. L2 execution drastically reduces gas usage across all functions. Functions with cryptographic overhead (e.g., spendRT) achieve 96× improvement. Medium functions achieve over 130× reduction due to aggregation. Lightweight functions show improvements from 5× (small batch counts) to over 230× (large workloads). This shows that DARTIC scales efficiently with L2 zk-batching, supporting hundreds of operations per L1 call while preserving verifiability and security. E. On-Chain Cost and end-to-end (E2E) Latency

generation of the aggregation proof. For the largest batch, this results in 49.6s, which remains within 5% of the baseline. Verification, on the other side, exhibits a sharper pattern. In the absence of aggregation, the system can accommodate at most 80 proof verifications per second (1-second block), yielding verification latencies that grow from 0.84s (64 proofs) to 8.7s (1024 proofs). By contrast, on-chain verification of aggregated proofs achieves logarithmic scaling, with a latency bounded between 0.84s and 0.96s across all batch sizes. As a result, aggregation is nearly cost-free for proving and cuts on-chain verification by an order of magnitude. 3. Gas Efficiency of L2 vs L1. We now evaluate the gas consumption of key system functions on Layer 2 (zkSync6 ) relative to Layer 1. Each L1 call aggregates multiple L2 batches, with the maximum aggregation factor m determined by function complexity and L1 gas limits. Heavy functions (spendAT, spendRT): m = 2 Medium functions (mintAT, mintRT, deposit): m = 3 • Light functions (withdraw, useRT, updateRT): m = 8 • •

The total gas cost on L2 is computed as: Gtotal,L2 = ⌈

#batches #batches ⌉ · Gcommit + ⌈ ⌉ · Gverify m m #batches +⌈ ⌉ · Gexecute (5) m

where Gcommit , Gverify , Gexecute denote the base gas cost of a single aggregated call handling up to m batches. The ceiling 6 https://docs.zksync.io/zksync-era

We compare the on-chain costs and latency with two representative privacy frameworks with comparable decentralized settings: AVeCQ [20], Duaan et al. [19], focusing on their E2E efficiency and scalability with respect to the number of workers. Table V summarizes the findings. The on-chain cost for DARTIC depends on the number of workers N and is composed of several contributions: Task creation: newTask = 289,070 gas; Participation: subToTask = 179,180×N gas; Worker selection: 33,200 gas; Reputation update: updateRT = 31,950 × N gas; and Reputation token spending (optimal window = 5): 15 · 1,244,750 × N = 248, 950 × N gas. This yields a total gas cost without aggregation: GasDARTIC = 322,270 + 460,080 · N gas. With SnarkPack aggregation (64 proofs per on-chain verification for both subToTask and spendRT), the gas cost is significantly reduced: Gasagg DARTIC = 322,270 + 38,640 · N gas. For image annotation tasks, AVeCQ [20] reports an onchain cost of 19 MWei for 39 workers. The cost of average review tasks scales approximately linearly with the number of workers, reaching 55 MWei for 128 workers. Thus, AVeCQ has a cost that is proportional to task complexity and worker participation. Duaan et al. [19] evaluate on-chain review tasks. With 128 workers, the E2E latency is reported at approximately 30 minutes, and the on-chain cost reaches 416 MWei per task, mainly due to complete on-chain execution. DARTIC outperforms both frameworks in terms of E2E latency. With respect to on-chain costs, it outperforms Duaan et al. [19] both with and without aggregation, and surpasses AVeCQ [20] when aggregation is employed. This efficiency stems from offloaded computations, where task evaluation and threshold signature generation are performed off-chain

14

(with latency <1s per submission), with only aggregated results submitted on-chain. As a result, DARTIC achieves taskagnostic cost efficiency and minimal latency. VII. C ONCLUSION This work studied how on-chain crowdsourcing can reconcile unlinkable anonymity, robust reputation binding, and scalability without relying on trusted intermediaries. We introduced DARTIC, a decentralized and anonymous trust framework that decouples identity management from service execution through a dual-ledger architecture and zkSNARK set membership proofs. This design enables users to operate under multiple unlinkable pseudonyms while preventing Sybil and reputation-reset attacks. In addition, we designed an automated, privacy-preserving reputation model driven by verifiable service outcomes to maintain accountability. For practical deployability, we studied proof aggregation and zkcompatible batching mechanisms to significantly reduce verification overhead and on-chain costs. Experimental evaluation demonstrates that DARTIC achieves sub-3s proof generation, sub-second on-chain verification, and over an orderof-magnitude improvement in verification efficiency. These results confirm DARTIC’s capability to support large-scale, anonymous, trustless Web3 crowdsourcing with strong resistance to identity and reputation manipulation. R EFERENCES [1] M. Li, J. Weng, A. Yang, W. Lu, Y. Zhang, L. Hou, J.-N. Liu, Y. Xiang, and R. H. Deng, “CrowdBC: A Blockchain-Based Decentralized Framework for Crowdsourcing,” IEEE Transactions on Parallel and Distributed Systems, vol. 30, no. 6, pp. 1251–1266, 2019. [2] S. Gao, X. Chen, J. Zhu, X. Dong, and J. Ma, “TrustWorker: A Trustworthy and Privacy-Preserving Worker Selection Scheme for BlockchainBased Crowdsensing,” IEEE Transactions on Services Computing, vol. 15, no. 6, pp. 3577–3590, 2022. [3] X. Liu, S. X. Sun, and G. Huang, “Decentralized services computing paradigm for blockchain-based data governance: Programmability, interoperability, and intelligence,” IEEE Transactions on Services Computing, vol. 13, no. 2, pp. 343–355, 2019. [4] Y. Lu, Q. Tang, and G. Wang, “ZebraLancer: Private and anonymous crowdsourcing system atop open blockchain,” in 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS). IEEE, 2018, pp. 853–865. [5] K. Zhao, S. Tang, B. Zhao, and Y. Wu, “Dynamic and privacy-preserving reputation management for blockchain-based mobile crowdsensing,” IEEE Access, vol. 7, pp. 74 694–74 710, 2019. [6] Y. Yu, S. Liu, L. Guo et al., “CrowdR-FBC: A distributed fogblockchains for mobile crowdsourcing reputation management,” IEEE Internet of Things Journal, vol. 7, no. 9, pp. 8722–8735, 2020. [7] O. Hasan, L. Brunie, and E. Bertino, “Privacy-preserving reputation systems based on blockchain and other cryptographic building blocks: A survey,” ACM Computing Surveys, vol. 55, no. 2, pp. 1–37, 2022. [8] E. Yu, Y. Xu, L. Gao, J. Cao, Q. Xiang, and L. He, “R-Manager: Consortium Blockchain-Based Vehicle Reputation Management for HighQuality Reports in Traffic-Oriented Crowdsourcing,” IEEE Transactions on Vehicular Technology, vol. 74, no. 1, pp. 984–999, 2025. [9] P. Wang, Z. Li, B. Guo, S. Long, S. Guo, and J. Cao, “A UAV-Assisted Truth Discovery Approach With Incentive Mechanism Design in Mobile Crowd Sensing,” IEEE/ACM Transactions on Networking, vol. 32, no. 2, pp. 1738–1752, 2024. [10] Z. Wu, D. Ding, Y. Xiu, Y. Zhao, and J. Hong, “Robust qos prediction based on reputation integrated graph convolution network,” IEEE Transactions on Services Computing, vol. 17, no. 3, pp. 1154–1167, 2023. [11] J. Huang, L. Kong, L. Cheng, H.-N. Dai, M. Qiu, G. Chen, X. Liu, and G. Huang, “BlockSense: Towards trustworthy mobile crowdsensing via proof-of-data blockchain,” IEEE Transactions on Mobile Computing, vol. 23, no. 2, pp. 1016–1033, 2022.

[12] M. M. Dif, M. A. Bouchiha, M. Rabah, and Y. Ghamri-Doudane, “AutoDFL: A Scalable and Automated Reputation-Aware Decentralized Federated Learning,” in IEEE/IFIP Network Operations and Management Symposium (NOMS), 2025, pp. 1–9. [13] D. Liu, A. Alahmadi, J. Ni et al., “Anonymous reputation system for IIoT-enabled retail marketing atop PoS blockchain,” IEEE Transactions on Industrial Informatics, vol. 15, no. 6, pp. 3527–3537, 2019. [14] M. A. Bouchiha, Y. Ghamri-Doudane, M. Rabah, and R. Champagnat, “DARS: Empowering Trust in Blockchain-Based Real-World Applications with a Decentralized Anonymous Reputation System,” in Advanced Information Networking and Applications. Springer, 2024, pp. 48–61. [15] X. Chen, B. Yang, Q. He, S. Zhang, T. Wang, H. Song, and A. Liu, “An anonymous, trust and fairness based privacy preserving service construction framework in mobile crowdsourcing,” IEEE Transactions on Services Computing, vol. 18, no. 2, pp. 618–632, 2025. [16] T. Dimitriou, “Decentralized reputation,” in 11th ACM Conference on Data and Application Security and Privacy. ACM, 2021, pp. 119–130. [17] A. Schaub, R. Bazin, O. Hasan, and L. Brunie, “A trustless privacypreserving reputation system,” in 31st IFIP International Information Security and Privacy Conference (SEC). Springer, 2016, pp. 398–411. [18] Q. Deng, Q. Zuo, Z. Li, H. Liu, and Y. Xie, “Blockchain-Based Reputation Privacy Preserving for Quality-Aware Worker Recruitment Scheme in MCS,” IEEE/ACM Transactions on Networking, vol. 32, no. 6, pp. 5188–5203, 2024. [19] H. Duan, Y. Zheng, Y. Du, A. Zhou, C. Wang, and M. H. Au, “Aggregating crowd wisdom via blockchain: A private, correct, and robust realization,” in 2019 IEEE International Conference on Pervasive Computing and Communications (PerCom). IEEE, 2019, pp. 1–10. [20] V. Koutsos, S. Damle, D. Papadopoulos, S. Gujar, and D. Chatzopoulos, “AV eCQ: Anonymous Verifiable Crowdsourcing With Worker Qualities,” IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 1, pp. 406–423, 2024. [21] Y. Guo, H. Xie, Y. Miao et al., “FedCrowd: A federated and privacypreserving crowdsourcing platform on blockchain,” IEEE Transactions on Services Computing, vol. 15, no. 4, pp. 2060–2073, 2022. [22] J. Chen, W. Liang, L. Xiao, C. Yang, R. Zhang, Z. Gui, and A. Poniszewska-Marańda, “PrivBCS: a privacy-preserving and efficient crowdsourcing system with fine-grained worker selection based on blockchain,” Connection Science, vol. 35, no. 1, p. 2202837, 2023. [23] R. Xiong, W. Ren, S. Zhao, J. He, Y. Ren et al., “CoPiFL: A collusion-resistant and privacy-preserving federated learning crowdsourcing scheme using blockchain and homomorphic encryption,” Future Generation Computer Systems, vol. 156, pp. 95–104, 2024. [24] F. Zhang, D. Maram, H. Malvai, S. Goldfeder, and A. Juels, “DECO: Liberating Web Data Using Decentralized Oracles for TLS,” in 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2020, pp. 1919–1938. [25] D. Maram, H. Malvai, F. Zhang, N. Jean-Louis, A. Frolov, T. Kell, T. Lobban et al., “CanDID: Can-do decentralized identity with legacy compatibility, sybil-resistance, and accountability,” in IEEE Symposium on Security and Privacy (S&P). IEEE, 2021, pp. 1348–1366. [26] M. Rosenberg, J. White, C. Garman, and I. Miers, “zk-creds: Flexible Anonymous Credentials from zkSNARKs and Existing Identity Infrastructure,” in 2023 IEEE Symposium on Security and Privacy (S&P). IEEE, 2023, pp. 790–808. [27] L. Lamport, R. Shostak, and M. Pease, “The Byzantine generals problem,” in Concurrency: the works of Leslie Lamport, 2019, pp. 203–226. [28] D. R. Kuhn, V. Hu, W. T. Polk, and S.-J. Chang, SP 800-32. Introduction to public key technology and the federal PKI infrastructure. National Institute of Standards & Technology, 2001. [29] A. Miller, Y. Xia, K. Croman, E. Shi, and D. Song, “The honey badger of BFT protocols,” in 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2016, pp. 31–42. [30] L. Breidenbach et al., “Chainlink 2.0: Next steps in the evolution of decentralized oracle networks,” Chainlink, White paper, vol. 1, 2021. [31] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town Crier: An authenticated data feed for smart contracts,” in ACM SIGSAC Conference on Computer and Communications Security. ACM, 2016, pp. 270–282. [32] R. Gennaro, “Multi-trapdoor commitments and their applications to proofs of knowledge secure under concurrent man-in-the-middle attacks,” in 24th Annual International Cryptology Conference (CRYPTO 2004). Springer, 2004, pp. 220–236. [33] R. Gennaro and S. Goldfeder, “Fast multiparty threshold ECDSA with fast trustless setup,” in 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2018, pp. 1179–1194. [34] ——, “One round threshold ecdsa with identifiable abort,” Cryptology ePrint Archive, Paper 2020/540, 2020.

15

[35] S. Das, T. Yurek, Z. Xiang, A. Miller, L. Kokoris-Kogias, and L. Ren, “Practical asynchronous distributed key generation,” in IEEE Symposium on Security and Privacy (S&P). IEEE, 2022, pp. 2518–2534. [36] J. Groth, “On the size of pairing-based non-interactive arguments,” in 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, 2016, pp. 305–326. [37] A. Gabizon, Z. J. Williamson, and O. Ciobotaru, “PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge,” Cryptology ePrint Archive, Paper 2019/953, 2019. [38] D. Benarroch, M. Campanelli, D. Fiore, K. Gurkan et al., “Zeroknowledge proofs for set membership: efficient, succinct, modular,” Designs, Codes and Cryptography, vol. 91, no. 11, pp. 3457–3525, 2023. [39] S. Micali, M. Rabin, and S. Vadhan, “Verifiable random functions,” in 40th annual symposium on foundations of computer science (cat. No. 99CB37039). IEEE, 1999, pp. 120–130. [40] J. Benet, “IPFS - Content Addressed, Versioned, P2P file system,” arXiv preprint arXiv:1407.3561, 2014. [41] A. Das and M. M. Islam, “Securedtrust: A dynamic trust computation model for secured communication in multiagent systems,” IEEE Transactions on Dependable and Secure Computing, vol. 9, no. 2, pp. 261– 274, 2011. [42] A. Pertsev, R. Semenov, and R. Storm, “Tornado cash privacy solution version 1.4,” White paper, vol. 1, p. 7, 2019. [43] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The secondgeneration onion router,” in 13th USENIX security symposium, vol. 4, 2004, pp. 303–320. [44] V. Nikolaenko, S. Ragsdale, J. Bonneau, and D. Boneh, “Powers-ofTau to the people: Decentralizing setup ceremonies,” Cryptology ePrint Archive, Paper 2022/1592, 2022. [45] Y. LeCun et al., “The MNIST database of handwritten digits,” 2005. [46] A. Krizhevsky, G. Hinton et al., “Learning multiple layers of features from tiny images,” 2009. [47] J. J. Li, B. Faltings, O. Saukh, D. Hasenfratz, and J. Beutel, “Sensing the air we breathe—the opensense zurich dataset,” in AAAI Conference on Artificial Intelligence (AAAI), vol. 26, no. 1, 2012, pp. 323–325. [48] N. Gailly, M. Maller, and A. Nitulescu, “Snarkpack: Practical snark aggregation.” Berlin, Heidelberg: Springer-Verlag, 2022, p. 203–229. [49] T. Liu, T. Xie, J. Zhang, D. Song, and Y. Zhang, “Pianist: Scalable zkrollups via fully distributed zero-knowledge proofs,” in IEEE Symposium on Security and Privacy (S&P). IEEE, 2024, pp. 1777–1793. [50] A. P. Kalapaaking, I. Khalil, and X. Yi, “Blockchain-Based Federated Learning With SMPC Model Verification Against Poisoning Attack for Healthcare Systems,” IEEE Transactions on Emerging Topics in Computing, vol. 12, no. 1, pp. 269–280, 2024. [51] R. Wang, X. Wang, H. Chen et al., “Mudguard: Taming malicious majorities in federated learning using privacy-preserving byzantinerobust clustering,” ACM on Measurement and Analysis of Computing Systems, vol. 8, no. 3, pp. 1–41, 2024. [52] K. L. Huang, S. S. Kanhere, and W. Hu, “Are you contributing trustworthy data? the case for a reputation system in participatory sensing,” in ACM international conference on Modeling, analysis, and simulation of wireless and mobile systems (MSWiM), 2010, pp. 14–22.

A. R EPUTATION M ODELING This appendix presents two instantiations of our reputation model. More precisely, it explains how interactions are evaluated and how reputations are updated in crowdsensing and federated learning scenarios. 1) Interaction Evaluation: The evaluation must preserve privacy: the reputation model neither uses nor reveals workers’ historical and sensitive data. Each interaction is weighted with Eq. (1) and the contribution from a worker v is evaluated using Eq. (2). Each parameter value Pjv , e.g., feedback, is associated with a corresponding weight, denoted by αj . In the following, we show two possible instantiations of Eq. (2). Crowdsensing tasks. The evaluation uses both subjective feedback and objective data quality metrics: hX i T v = α1 Ou,v + αk Qk Qo

where, Ou,v is the subjective metric (i.e., the direct opinion of the requester u) and Qk represents objective data quality metrics, including: |ai −ā| • Data Consistency: Qc = 1 − max(|a |,|ā|) i • Data Freshness: Qf = exp(−λ(tcurrent − tsubmission )) Valid Fields • Data Completeness: Qcomp = Total Fields The outlier score Qo flags anomalies using a robust statistical method (e.g., DBSCAN). Federated learning tasks. A straightforward yet impractical initial approach would be to evaluate the models using a central auxiliary (a.k.a. root) dataset. However, this contradicts the fundamental goals of federated learning and the principles of our DARTIC, as it introduces privacy risks by relying on a centralized dataset for evaluation [50], [51]. To avoid this, we propose a robust approach that replaces accuracy-based evaluation with cosine similarity and clustering. Specifically, we employ cosine similarity between local model updates and the global model. This allows us to measure the alignment of local updates with the global optimization direction without requiring a separate validation dataset. Furthermore, clustering is used to filter outliers and potential adversarial updates. • Cosine Similarity for Evaluating Model Updates. We define the cosine similarity between the global model Θt and the local model update g v,t+1 from worker v as: cos(θv ) =

⟨Θt , g v,t+1 ⟩ . ∥Θt ∥ · ∥g v,t+1 ∥

Benign workers typically produce updates that are aligned with the global model as training progresses, whereas malicious updates exhibit less similarity due to adversarial intent. • Clustering for Filtering Malicious Updates. To further enhance robustness, we apply clustering to the cosine similarity scores. Given a set of cosine similarity values for all workers, we normalize them as follows: csiv =

cos(θv ) − min(cs) . max(cs) − min(cs)

We define a threshold based on the mean similarity score: τ = mean(cs). Workers with csiv > τ are retained for aggregation, ensuring that adversarial updates are excluded. Instead of accuracy-based metrics, we redefine the trust score by tracking how frequently the clustering mechanism over multiple rounds selects the local model update from worker i. We define the selection frequency SF v as follows: ν

SF v =

t 1 X I(LM v selected in round t), νt t=1

where I(·) is an indicator function that returns 1 if the model is selected in round t and 0 otherwise, νt is the total number of rounds. The final score of the worker v integrates both direct feedback and the reliability of v’s contributions. T v = α1 · Ou,v + α2 · SF v This ensures that the evaluation aligns with the decentralized and privacy-preserving goals of DARTIC.

Reputation

16

0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

Lemma 3 (Resistance to reputation inflation). For any sequence of interactions with bounded trust values, the deviation from the long-term trust level T̄ satisfies

Positive ( = 0.2, T + = 0.9) Negative ( = 0.6, T = 0.1) T + (target) T (target) R 0 (initial)

0

5

10

15

20

Interactions

25

|Rv,n − T̄ | ≤ (1 − γWf )n |Rv,0 − T̄ |. Thus, manipulation attempts through intermittent high-trust interactions produce only exponentially bounded influence. Proof. Follows directly from the affine contraction form of Eq. (3). □

30

Fig. 7: Asymmetric dynamics of reputation updates with PWMean.

2) Reputation Update: Global reputation scores are updated using a piecewise-weighted mean (PW-Mean) function Eq. (3). As shown in Fig. 7, this asymmetry ensures that malicious interactions have a stronger impact than positive ones, making reputation harder to build than to lose. 3) Theoretical properties of the PW-Mean update: We analyze the PW-Mean fundamental mathematical properties. The update rule in Eq. (3) defines a bounded stochastic dynamical system driven by trust observations. We show that it (i) preserves reputation values within valid limits, (ii) ensures smooth and stable evolution under arbitrary trust sequences, (iii) provides intrinsic resistance against reputation inflation and manipulation, (iv) exhibits asymmetric sensitivity to positive and negative interactions, and (v) converges toward the underlying trust level under stochastic observations. These formally establish that the parameters ψ and ξ directly control the adaptation speed and security sensitivity of the system, while the threshold Tθ governs the transition between rewarddominated and penalty-dominated regimes. Lemma 1 (Boundedness). Assume Rv,0 ∈ [0, 1] and T v,i ∈ [0, 1] for all i. Then R

v,i

∈ [0, 1],

∀i ≥ 0.

Lemma 4 (Asymmetric sensitivity). Let two interactions have identical weight Wf and equal trust deviation magnitude δ > 0: T + = R + δ,

T− = R − δ

then

ξ |∆− | = > 1. |∆+ | ψ

Proof. Directly from Eq. (3): |∆+ | = ψWf δ

and

|∆− | = ξWf δ □

Result follows.

Lemma 5 (Contraction and deterministic convergence). For fixed trust value T̄ , reputation converges exponentially: Rv,i+n = (1 − γWf )n Rv,i + (1 − (1 − γWf )n ) T̄ Thus Rv,i+n → T̄ . Proof. Obtained by unrolling the recurrence relation. □ Theorem 1 (Convergence under stochastic trust). Assume trust values are independent random variables with expectation E[T v,i ] = µ. Then lim E[Rv,i ] = µ.

i→∞

Proof. Taking expectation in Eq. (3): E[Rv,i+1 ] = (1 − γWf )E[Rv,i ] + γWf µ This linear recurrence converges to µ.

Proof. From Eq. (3), the update can be written as

□

Rv,i+1 = (1 − γWf )Rv,i + γWf T v,i ,

B. S ECURITY A NALYSIS

where γ ∈ {ψ, ξ} and 0 ≤ γWf ≤ 1. Thus Rv,i+1 is a convex combination of two values in [0, 1], implying Rv,i+1 ∈ [0, 1]. The result follows by induction. □

The following security analysis applies to both zkSet circuits (Access Control and Reputation Binding). 1. Completeness: Definition 7.1: Completeness ensures that if the prover’s statement x is valid (i.e., x ∈ L, where L is the language of valid statements) and the prover follows the protocol honestly, the verifier will always accept the proof. Proof Sketch. • For access control: 1. The prover knows a, and the cryptographic commitment cmA is correctly computed as cmA = COMM(a, A). 2. cmA appears as a leaf in the Merkle tree ACT ree with root rtA . • For reputation binding: 1. The prover knows b, and the cryptographic commitment cmR is correctly computed as cmR = COMM(b, R).

Lemma 2 (Stability under time-varying trust). For any bounded trust sequence T v,i ∈ [0, 1], the reputation evolution satisfies |Rv,i+1 − Rv,i | ≤ γWf . Proof. From Eq.(3), |Rv,i+1 − Rv,i | = γWf |T v,i − Rv,i | Since all values lie in [0, 1], |T v,i − Rv,i | ≤ 1 which yields the result.

□

17

cmR appears as a leaf in the Merkle tree RCT ree with root rtR . • zkSNARK enforces these conditions using the following algorithms: – Commitment constraints: cm = COMM(secret, public). – Merkle proof constraints: Ensure the commitment appears as a leaf in the tree and the root matches rt. • By the completeness property of zkSNARKs, an honest prover with a valid proof π should convince the verifier. Formally, for any probabilistic polynomial-time (PPT) adversary A, we have: 2.

 pp ← Step(1λ ),   (C, (x, w)) ← A(pp),   =1 (pp, C, x, w) ∈ L, Verif(V K, x, π) = 1 Pr      (V K, P K) ← Gen(pp, C), π ← Prov(P K, cm, Merkle path) 

2. Soundness: Definition 7.2 (Soundness): ensures that no malicious prover can convince the verifier to accept a false statement x ∈ / L except with negligible probability. Proof Sketch. • The statement x corresponds to the root of the Merkle tree (rtA for access control or rtR for reputation binding). • The witness w consists of: – The secret (a or b), – The cryptographic commitment (cmA = COMM(a, A) or cmR = COMM(b, R)), – The Merkle path proving that cmA or cmR is a leaf of the tree. • Knowledge soundness means that a prover cannot forge a valid proof π without knowledge of a valid witness w. Formally, for all PPT adversaries A, there exists a PPT extractor ε such that for all randomness ρ, we have:   Verif(V K, x, π) = 1, Pr   (x, w) ∈ /L

 pp ← Setup(1λ ),  (x, π) ← A(pp; ρ),  ≤ negl(λ) (V K, P K) ← Gen(pp, C),  w ← ε(pp, ρ)

The zkSNARK system guarantees knowledge soundness: – If the adversary A produces a valid proof π for x such that x ∈ / L, the extractor ε can efficiently extract a valid w from the proof. – This is possible because the zkSNARK enforces all constraints algebraically, ensuring that any valid proof corresponds to a valid witness. • Cryptographic assumptions ensure the adversary cannot: 1. Forge a cryptographic commitment cmA or cmR without knowledge of the secret (a or b), 2. Forge a Merkle path without breaking the collisionresistant hash (CRH) function, 3. Produce a valid zkSNARK proof without satisfying the circuit constraints. Finally, by the knowledge soundness of zkSNARKs, if A produces a valid proof π, the extractor ε can efficiently recover a valid witness w, ensuring that the statement x is true. Thus, the probability of A producing a valid proof for a false statement x ∈ / L is negligible under standard cryptographic •

TABLE VI: Gas consumption of key functions: L1 vs L2 with batch scaling. Function #Total Calls #Batches Commit Verify Execute Total (L2) Total (L1) Improvement (×) 64 3 263,609 83,676 99,166 446,451 59,888,000 134.2 mintAT 512 24 2,108,872 668,608 793,328 3,570,808 479,104,000 134.2 1024 48 4,217,744 1,337,216 1,586,656 7,141,616 958,208,000 134.2 64 3 256,324 83,676 99,166 439,166 58,340,864 132.9 deposit 512 24 2,050,592 668,608 793,328 3,512,528 466,726,912 132.9 1024 48 4,101,184 1,337,216 1,586,656 7,025,056 933,453,824 132.9 64 3 453,264 167,352 198,332 818,948 78,672,000 96.1 spendAT 512 24 3,618,112 1,338,816 1,586,656 6,543,584 629,376,000 96.2 1024 48 7,236,224 2,677,632 3,173,312 13,087,168 1,258,752,000 96.2 64 1 261,944 83,676 99,166 444,786 19,889,600 44.7 withdraw 512 8 261,944 83,676 99,166 444,786 159,116,800 357.3 1024 24 785,832 251,028 297,498 1,334,358 318,233,600 238.5 64 3 268,843 83,676 99,166 451,685 61,161,408 135.5 mintRT 512 24 2,150,744 668,608 793,328 3,612,680 489,291,264 135.5 1024 48 4,301,488 1,337,216 1,586,656 7,225,360 978,582,528 135.5 64 4 502,000 167,352 198,332 867,684 79,664,000 91.9 spendRT 512 32 4,016,000 1,338,816 1,586,656 6,941,472 637,312,000 91.8 1024 64 8,032,000 2,677,632 3,173,312 13,882,944 1,274,624,000 91.8 64 1 245,600 83,676 99,166 428,442 20,204,800 47.2 useRT 512 8 245,600 83,676 99,166 428,442 161,638,400 377.3 1024 24 737,000 251,028 297,498 1,285,526 323,276,800 251.5 64 1 219,584 83,676 99,166 402,426 2,044,800 5.1 updateRT 512 1 219,584 83,676 99,166 402,426 16,358,400 40.6 1024 2 439,168 167,352 198,332 804,852 32,716,800 40.7

assumptions. 3. Zero-Knowledge: Definition 7.3 (Zero-knowledge): A proof system is zeroknowledge if for any probabilistic polynomial-time (PPT) adversary A, there exists a PPT simulator S such that the simulated proof is computationally indistinguishable from a real proof, given only the statement x. Proof Sketch. • Consider a zkSNARK proof system with a common reference string (CRS). • There exists a simulator S that, given the statement x and access to the simulation trapdoor associated with the CRS, can generate a simulated proof πS without knowledge of the witness w. • Indistinguishability: For any PPT adversary A and security parameter λ, |Pr[A(x, π) = 1] − Pr[A(x, πS ) = 1]| ≤ negl(λ) where π is a real proof generated using witness w, and πS is generated by the simulator. • Therefore, the adversary cannot distinguish whether the proof was generated using the witness or simulated, implying that no information about w is revealed. C. A DDITIONAL R ESULTS This appendix presents the additional results. 4) Scalability: We evaluate the gas consumption of selected functions in our system, comparing execution on Layer 2 (zkSync) versus Layer 1 (EVM). The functions tested include mintAT, deposit, spendAT, withdraw, mintRT, spendRT, useRT, and updateRT. Each function may operate on multiple L2 batches, and zkSync allows aggregated submission of multiple batches per L1 transaction. L2 Batch Aggregation Rules. Let #batches denote the number of L2 batches to be processed, and m denote the maximum number of batches that can be aggregated in a single L1 call, depending on the function weight and L1 gas limits:

18

mintAT, mintRT, deposit: m = 3 • spendAT, spendRT: m = 2 • withdraw, useRT, updateRT: m = 8 •

v1 (W-Mean) v3 (W-Mean) v5 (W-Mean)

v1 (Gompertz) v3 (Gompertz) v5 (Gompertz)

10

20

5

0.8

Reputation

The total gas cost on L2 is computed as:

v1 (PW-Mean) v3 (PW-Mean) v5 (PW-Mean)

0.6 0.4

where Gcommit , Gverify , Gexecute denote the base gas cost of a single aggregated call handling up to m batches. The ceiling function ⌈·⌉ accounts for partially filled aggregated calls. L1 Gas Cost. The L1 gas cost is dominated by calldata submission and on-chain computation. Each aggregated call incurs approximately the same cost per function. Therefore, the L1 total gas cost scales linearly with the total number of calls: (8) Gtotal,L1 = #total calls · GL1 Table VI highlights the efficiency gains obtained by operating on L2 with aggregated batch submission. Functions with heavier computation and higher L1 gas footprints (mintAT, mintRT, deposit) benefit substantially from aggregation. By grouping m = 3 batches per L1 transaction, the L2 total gas cost grows slowly compared to the L1 cost, resulting in improvements of over 130×. For lighter functions such as updateRT, withdraw, and useRT, m is larger (up to 8) to maximize batch aggregation. This allows multiple L2 updates to be included in a single L1 call, keeping L2 gas almost constant for small numbers of batches. The improvement factor ranges from 5× (for very small batch counts) up to 250× for larger workloads. Functions like spendAT and spendRT, which involve cryptographic operations (e.g., pairing for the verifier and 40 MiMCSponge calls for inserting a new leaf), have a lower aggregation factor (m = 2). While this limits the degree of batching, the L2 gas cost is still one to two orders of magnitude lower compared to L1, with improvements up to 96×. Equations (7) and (8) show that L2 gas scales with the number of L1 calls, not linearly with total batches. This explains why L2 gas for withdraw or updateRT remains nearly constant for up to 512 operations (i.e., L2 handled 512 transaction with one single L1 call). In contrast, L1 gas scales strictly linearly with the number of operations. The analysis confirms that L2 batch aggregation drastically reduces gas consumption while maintaining security and verifiability. In practice, the system can handle hundreds to thousands of transactions per L1 block, providing a scalable solution for high-frequency operations in DARTIC such as token minting and spending. The improvement factors reported in Table VI quantify this efficiency, demonstrating the advantage of L2 execution for both heavy and lightweight functions. 5) Reputation Effectiveness: We simulate three different workers’ behaviors for the learning tasks as follows: (i) Honest. consistently engage in training the model (v4, v5, v6, v8, v9). (ii) Malicious. attempt to poison the model

0.2 0

5

15

#Task (CNN)

0

10

15

#Task (ResNet)

20

(a) Learning tasks v10 (PW-Mean) v11 (PW-Mean) v12 (PW-Mean)

v10 (W-Mean) v11 (W-Mean) v12 (W-Mean)

v10 (Gompertz) v11 (Gompertz) v12 (Gompertz)

0.8 Reputation

#batches #batches Gtotal,L2 = ⌈ ⌉ · Gcommit + ⌈ ⌉ · Gverify m m #batches +⌈ ⌉ · Gexecute (7) m

0.6 0.4 0.2 0

5

10 15 #Tasks (Sensing)

20

(b) Sensing tasks

Fig. 8: Comparison of reputation models: our PW-Mean vs. W-Mean vs. Gompertz.

by submitting malicious weights (vary in magnitude or direction; v3, v7) .(iii) Lazy. Free-ride/skip rounds and actively participate in only a portion (40% − 60%; v1, v2). For crowdsensing, workers profiles are: honest (v12), malicious (v11), and lazy (10). Honest workers submit accurate, complete, and consistent environmental data, whereas malicious and lazy workers exhibit deviations or inconsistencies in their submissions. Fig.8 compares our PW-Mean with two commonly used aggregation techniques: Weighted Mean (WMean [18] and Gompertz function [52] over a sequence of learning tasks. Both outperform simple Sum and Mean baselines [2], [20], with a more stable convergence. Although all three methods maintain good consistency, PW-Mean proves to be the most robust. Honest workers (e.g., v5, and similarly v4, v6, v8, v9, v12) experience steady reputation gains, while malicious (e.g., v3, v11) and lazy (e.g., v1, v10) behaviors lead to notable declines, with malicious actions incurring the steepest penalties. The PW-Mean model exposes occasional contributions from free riders (e.g., v1) by linking penalties to missed rounds. Unlike W-Mean and Gompertz, PW-Mean introduces asymmetric reputation dynamics, which ensure gradual reward for honest behavior while swift punishment for misconduct. It also adapts to varying task sizes, with malicious actions causing sharper drops in larger tasks (e.g., ResNet on CIFAR-10). This is evidenced by the decline rates observed for worker v3, which highlight that PW-Mean achieve more reliable and realistic convergence. 6) Optimal RT Reuse Window: Workers may reuse a reputation token (RT) across multiple interactions to benefit from continuity (i.e., a stable presentation of recent reputation and smoother task acceptance). However, longer reuse windows increase (i) linkability risk and exposure to retaliation/badmouthing, and (ii) the blast radius when targeted. Frequent rotation limits these risks but introduces minting overhead and

19

fragments auditor signals. We seek an optimal reuse window W ⋆ ∈ N (number of interactions per RT) that balances privacy, safety, and cost. To this end, we consider the following: H1. (Privacy–Safety) Linkability risk Link(W ) and expected retaliation damage Ret(W ) grow with W (sublinearly to saturating), yielding a knee in the risk curve. H2. (Cost) On-chain overhead decreases with W (fewer rotations), inducing counter-pressure toward larger W . H3. (Task Sensitivity) learning tasks exhibit a different curve from sensing tasks because learning involves higher complexity (data handling and training) compared to sensing. The experiment varies the following independent variables: • RT reuse window W . W ∈ {1, 2, 3, 5, 8, 13, 21} (Fibonacci grid for higher resolution at small W ). • Adversary type. We consider three types of attacks: (i) Random bad-mouthing: i.i.d. negative ratings with probability pneg . (ii) Retaliatory: negative ratings conditioned on victim’s prior negative. (iii) Coordinated shilling: m colluders push negatives within the same RT lifetime. • Reputation parameters. (defaults). κ=1.0, k=2 clusters, ψ<ξ, Tθ ; ablate (ψ, ξ) ∈ {(0.1, 0.3), (0.2, 0.6)}, Tθ ∈ {0.5, 0.6, 0.7}, and ω for Wf . We evaluate the trade-offs induced by W along four dimensions. The metrics include RAU (risk-adjusted utility), drawdown, cost on demand, AUClink (linkability), RSI (stability), and Prhire (W ) (probability that a worker remains above the hiring threshold). Table VII shows the impact of the RT reuse window W on these metrics under three adversarial scenarios: random, retaliatory, and collusive attacks. 1. Privacy & Linkability. Let Φ denote metadata observable by a network adversary or counterparties (e.g., time gaps, reward scale, coarse context bins, behavioral style). We train a pairwise classifier to predict same-AT vs. different-AT across interaction pairs. AUClink (W ) := ROC-AUC of the linkage classifier, k-Anon(W ) := avg. size of indistinguishable clusters per RT lifetime, I(AT ; Φpub ) := mutual information between AT/features. Φpub are the visible features derived from TXRS and TXRU (R, cmR , Sn , pseudos, zk-proofs) The results of the experiment (Fig.9a) show AUClink grows monotonically with W , from 0.005 at W = 1 to 0.0997 at W = 21. This shows a slight increase in risk of linking. Despite this, for moderate W (3–8), the risk remains low (<0.04), suggesting that the sweet spot that balances privacy and cost lies in the mid-range. 2. Safety Against Bad-Mouthing / Retaliation. Three metrics are used: Max drop from initial reputation,  
Drawdown(W ) = E max Rv,0 − Rv,t ; (9) t≤W

Time to recover to 95% of the initial reputation, TTR0.95 (W ) = E[min{t ≤ W : Rv,t ≥ 0.95 Rv,0 }] ; (10)

And the probability that reputation exceeds hiring threshold at any point: Pr (W ) = P(Rv,t ≥ Rhire ) (11) hire

Drawdown (Fig.9b) increases monotonically with W , as expected: longer RT lifetimes expose the worker to attacks. The effect is magnified for retaliatory and collusive attacks, reaching a maximum drawdown of 0.2143 at W = 21 for retaliatory adversaries, which confirms Hypothesis H1 (privacy-safety tradeoff). Prhire (W ) is maximal (1.0) for W ≤ 13 across all attacks, then declines for larger windows. This reflects the risk of overly long RT reuse, where workers may temporarily fall below the hiring threshold due to accumulated negative feedback. 3. Utility & Cost. Define risk-adjusted utility: RAU(W ) = E[Accepted tasks × reward] −λ1 Drawdown(W ) | {z } {z } | utility

safety loss

− λ2 AUClink (W ) −λ3 OnChainCost(W ), | {z } | {z } privacy loss

(12)

gas/latency

1 with, OnChainCost(W ) ∝ W × cost(mintRT+spendRT)

RAU generally increases from W = 1 to W = 8 across all attack types, peaking at W = 8 for random and W = 5 collusive attacks (cf. Figs.10b and 10a). This reflects the benefits of reduced minting/spending overhead, as well as more stable task acceptance, as the reuse window grows. However, for W ≥ 13, RAU declines despite lower onchain costs (Fig.11), indicating that privacy and safety losses outweigh marginal utility gains. 4. Stability. We use the reputation stability index RSI(W ) within each RT lifetime (higher is better), and Varlife (Rv ) variance of Rv across lifetimes (lower is better). RSI slightly decreases with W , especially under retaliatory and collusive attacks (Fig.10b and 10a), indicating that longer RT lifespans may expose workers to fluctuations. At small W , RSI remains near 1.0, which reflects minimal variance across rotations. 5. Optimal Window. RAU, drawdown, linkability, and cost trends (Fig.12) reveal an empirical sweet spot near: W ⋆ ∈ {3, 5, 8}, Specifically, small windows (W = 1–2) offer strong privacy and safety guarantees but incur high blockchain costs. Medium windows (W = 3–8) provide a balanced tradeoff between utility, cost, and privacy, making them the preferred choice in most scenarios. In contrast, large windows (W ≥ 13) yield only marginal utility gains while increasing exposure to attacks and linkability. These results empirically validate DARTIC’s design principle: dynamic and optimal RT reuse preserves unlinkability and reputation stability while minimizing onchain overhead.

20

TABLE VII: Effect of RT reuse window W under three attack types: random / retaliatory / collusive. W 1 2 3 5 8 13 21

RAU 0.7985 / 0.7985 / 0.7985 0.8924 / 0.8827 / 0.8909 0.9202 / 0.9020 / 0.9174 0.9371 / 0.9052 / 0.9323 0.9403 / 0.8936 / 0.9334 0.9351 / 0.8740 / 0.9264 0.9243 / 0.8534 / 0.9147

Metric Value

Cost 1.0000 0.5000 0.3333 0.2000 0.1250 0.0769 0.0476

AUClink 0.0050 0.0100 0.0149 0.0247 0.0392 0.0629 0.0997

RSI 1.0000 / 1.0000 / 1.0000 0.9954 / 0.9857 / 0.9939 0.9911 / 0.9726 / 0.9883 0.9836 / 0.9495 / 0.9783 0.9743 / 0.9212 / 0.9662 0.9627 / 0.8869 / 0.9515 0.9508 / 0.8524 / 0.9368

Prhire (W) 1.0000 1.0000 1.0000 1.0000 1.0000 1.0000 0.8029

1.0

4 AUClink ( ) k-Anon ( ) Mutual Info ( ) Retaliation Risk Ret(W) ( )

3 2 1 0

1 2 3

5

8

13

RT Reuse Window W

Safety Metric Value

5

Drawdown 0.0000 / 0.0000 / 0.0000 0.0092 / 0.0286 / 0.0123 0.0174 / 0.0536 / 0.0230 0.0309 / 0.0948 / 0.0406 0.0459 / 0.1393 / 0.0597 0.0612 / 0.1835 / 0.0787 0.0725 / 0.2143 / 0.0918

0.8 0.4 0.2 0.0

21

Drawdown ( safety) TTR0.95 ( recovery time) Prhire ( probability)

0.6

123

5

(a) Privacy & linkability

8

13

RT Reuse Window W

21

(b) Safety

Fig. 9: Privacy, linkability, and Safety vs. W under retaliatory attacks.

W values Knee W*=3 1.0

0.0

1 2 3

5

8

13

RT Reuse Window W

21

0.4 0.0

(a) Learning tasks: random

1 2 3

5

8

13

RT Reuse Window W

21

0.00

(b) Sensing tasks: collusive

Fig. 10: RAU, stability, cost. vs. W under random & collusive attacks.

Cost with SnarkPack Cost without SnarkPack Knee (SnarkPack) W=3 Knee (No SnarkPack) W=3

1.5 1.0 0.5 0.0

123

5

8

13

RT Reuse Window W

(a) Learning tasks

21

1e9

Gas / 1000 interactions

Gas / 1000 interactions

1e9 2.0

2

0.2

Cost with SnarkPack Cost without SnarkPack Knee (SnarkPack) W=3 Knee (No SnarkPack) W=5

2.0 1.5 1.0 0.5 0.0

123

5

8

13

RT Reuse Window W

21

(b) Sensing tasks

Fig. 11: Gas per 1000 interactions vs. W with/without SnarkPack aggregation.

3

5

8

13

0.08 0.06 0.04 0.02 0.02 A0.04 UCli0.06 nk 0.08 0.10 0.00

n

0.2

0.6

aw

0.4

1

RAU ( utility) On-chain cost (normalized, ) RSI ( stability) Var_life ( volatility)

Dr

0.6

1.0 0.8 0.6 0.4 0.2 21 0.0

OnChainCost

0.8 RAU ( utility) On-chain cost (normalized, ) RSI ( stability) Var_life ( volatility)

Metric Value

Metric Value

0.8

do w

1.0

Fig. 12: Pareto front over ⋆ (AUClink , Drawdown, OnChainCost) with knee Wknee highlighted.