RBCrowd: A Reliable Blockchain-Based Reputation Management Framework for Privacy Preservation in Mobile Crowdsensing

Abstract

Mobile crowdsensing (MCS) is an emerging paradigm that enables cost-effective, large-scale, and participatory data collection through mobile devices. However, the open nature of MCS raises significant privacy and trust challenges. Existing reputation models have made progress in assessing the quality of contributions, but they still struggle to manage prolonged inactivity, which can lead to outdated scores that no longer reflect current engagement. To address these issues, this paper presents RBCrowd, a dynamic reputation management system based on a dual blockchain architecture. It consists of the Sensing Chain (SC), a public blockchain recording sensing tasks and results, and the Reputation Chain (RC), a consortium blockchain managing user reputation scores. To guarantee privacy, the framework limits identity verification to the RC, ensuring that data on the SC is stored without direct links to the worker. We paired this privacy mechanism with a reputation model that rewards consistent, high-quality contributions. The system updates reputation scores by first validating the specific task and then adjusting for historical engagement, specifically penalizing prolonged inactivity. We evaluate RBCrowd through simulations in realistic MCS scenarios, and the results show that our framework provides more effective dynamic trust management than existing models. It also achieves increased reliability and fairness while managing prolonged inactivity through adaptive penalties.

1. Introduction

Mobile crowdsensing (MCS) has emerged as a flexible and cost-effective method for collecting large volumes of real-world data using smartphones and IoT devices [1,2]. It enables mobile users to collect and share sensor data [3], and has opened new possibilities for smart cities [4], intelligent transportation [5], and healthcare monitoring systems [6]. However, the open nature of MCS platforms raises persistent concerns about the reliability, trustworthiness, and privacy of both the data and the users. These concerns directly impact continued user participation and the success of any crowdsensing initiative. In traditional MCS systems, a centralized server acts as the sole intermediary responsible for the entire sensing life cycle, encompassing task creation, worker assignment, data analysis, reputation calculation, and reward distribution. However, this centralized architecture presents a critical single point of failure. Because the server is often semi-honest or potentially malicious, there is a lack of transparency and fairness in how tasks are assigned and how reputation scores are updated. If the central server is compromised, it can manipulate the reputation ledger to favor specific participants or demote honest workers, and it cannot technically guarantee privacy or data integrity against insider attacks.

Blockchain technology offers as a viable alternative to centralized authority in several domains. It was first suggested in 2009 by Satoshi Nakamoto [7] as a distributed ledger across a network of nodes without reliance on any central authority [8]. Each block in the chain is a list of transactions, with a timestamp, the cryptographic hash of the previous block, and its own hash, allowing for integrity, immutability, and sequential order in the data. In this decentralized paradigm, the MCS processes, such as the specific algorithms for data validation and the multi-factor formulas for reputation update, are immutably coded and publicly auditable. This ensures that no single entity, including the task requester, can unilaterally alter the system’s state or falsify records. The use of blockchain within MCS solves the major problems of centralized-based systems, but introduces others that must be considered [9], such as computation and storage overheads, scalability, and latency. Moreover, privacy and unlinkability problems still have to be tackled, since public ledgers can offer the opportunity of disclosing some metadata that may be sensitive. Finally, designing lightweight and context-aware trust management mechanisms on top of blockchain infrastructure is crucial to balance transparency, efficiency, and user confidentiality.

To solve these problems, researchers have presented blockchain-centered reputation management systems for MCS [10,11,12]. These systems quantify user trustworthiness and provide improved reliability of data, which reduces malicious activity [13]. The greater the user reputation score, the more reliable the user is in relation to their contributions, thereby increasing the probability that they will be assigned further tasks. Current reputation schemes have been shown to be very effective in detecting fraudulent contributions. However, there remain two other problems. The first is prolonged user inactivity, preventing up-to-date scores reflecting current involvement. In practice there may be long periods of inactivity which may misalign reputation scores with actual user behavior, thus exposing inactive users to undue trust or discouraging active contributors [14].

The second challenge concerns the preservation of privacy [15]. Most existing systems manage sensor data and reputation within a single blockchain, and directly storing this data on-chain reveals sensitive information [11,16]. This design increases storage overhead and links between workers’ identities, their contributions, and their reputation scores. This traceability compromises user privacy and also exposes participants to profiling attacks.

To address these issues, we propose RBCrowd, a reliable blockchain-based MCS framework. The novelty of RBCrowd extends beyond the application of blockchain technology; it introduces a comprehensive fully dynamic reputation management framework that addresses a critical gap in current MCS trust models: the management of user inactivity. Unlike traditional schemes that only update reputation scores after each contribution, RBCrowd’s reputation also updated in case of prolonged inactivity through an automated decay mechanism. This scheme ensures that reputation scores reflect real and continuous engagement. The integration of a dual-blockchain architecture serves as the technical foundation to protect this dynamic model. This design separates the public record of sensing tasks from the private management of reputation, thereby achieving privacy unlinkability. This ensures that while the system tracks the frequency and quality of contributions to maintain an accurate trust score, it simultaneously prevents the disclosure of sensitive metadata or the creation of searchable participant profiles. Furthermore, the framework also integrates the Interplanetary File System (IPFS) [17] to reduce the blockchain storage overhead and preserve data privacy. To the best of our knowledge, this article is the first to propose a fully dynamic reputation management framework based on a dual-blockchain architecture. The main contributions of this article are summarized below:

• A dual-blockchain architecture for MCS is proposed to separate sensing operations and reputation management into two distinct chains, namely, the Sensing Chain (SC) and the Reputation Chain (RC). The SC, designed as a public blockchain, records sensing tasks and results, while the RC, designed as a consortium blockchain, manages users’ reputation scores. This design enhances privacy by ensuring that identity verification occurs only within the RC, while submissions on the SC remain anonymous and unlinkable.
• A dynamic reputation update mechanism takes into account the quality and frequency of contributions. The quality of contributions is assessed based on validator feedback, data consistency, and contextual alignment, while the frequency of contributions is determined based on task completion rate and contribution frequency factors. To mitigate prolonged inactivity, an automatic decay mechanism is applied after each predefined maximum interval.
• The effectiveness of the proposed framework against potential internal attacks is assessed through comprehensive analyses and simulations, which also validate the fairness and responsiveness of the reputation system.

The remainder of this paper is organized as follows. Related works are summarized in Section 2. In Section 3, we present an overview of the proposed system. Section 4 describes the proposed reputation scheme in detail. The security analysis and simulations results are presented in Section 5. Finally, we conclude in Section 6.

2. Related Work

Reputation management has become a fundamental approach to enhance trust and reliability in MCS, where malicious behaviors are persistent threats [18]. Traditional MCS solutions often struggle to trade off effective detection of malicious users with robust protection of participant privacy. This challenge has motivated a diverse array of schemes in the literature, ranging from cryptography-driven privacy-preserving models to blockchain-based decentralized frameworks.

Zhao et al. [11] proposed a blockchain-based reputation system for MCS, called BC-MCS, that employs additive secret sharing to preserve users’ privacy. The reputation scheme integrates a multifactor weighted model considering data distortion, consistency, local ratings, and contextual factors. They also designed a delegation protocol to protect the system against user dynamics that leave the system after assignment without contributing data; however, they ignored penalizing this inactivity. All the system interactions occur on a single public blockchain, ensuring transparency and robustness against various attacks (e.g., single point of failure), but ignores the privacy of reputation scores and data content.

Other lines of work, exemplified by Zhao et al. [19], focus on a dynamic trust update system for Wireless Sensor Networks (WSNs) based on exponential functions, which facilitate rapid penalization of malicious behavior, including on–off and collusion attacks. Their system combines direct and indirect trust metrics, and applies entropy theory to determine when indirect trust should be incorporated. The introduction of a refined confidence factor further enhances the dynamic adaptation of node trust, mitigating the impact of compromised nodes. Despite these technical strengths, the solution is generally designed for static WSNs and lacks decentralization, which increases the risk of single point of failure and other attacks, and exposes the system to additional security vulnerabilities.

Decentralized approaches, such as CrowdR-FBC by Yu et al. [20], employ a hybrid fog-blockchain architecture and entropy-weighted multi-factor reputation. CrowdR-FBC leverages pseudo-identities and encrypted communication for privacy, but its reputation update process only responds to active participation, leaving the system vulnerable to strategic inactivity. A four-factor vector (accuracy, integrity, timeliness, history) is clustered with k-means to flag collusion, while only digests are anchored on-chain to cut storage and gas. Although it reduces ledger bloat, it still publishes raw reputation values, leaving the system vulnerable to inference attacks.

Other blockchain-based protocols like BTrust [21] advocate for a modular trust framework for general resource sharing scenarios, using smart contracts and watchdogs to penalize malicious behavior. BTrust integrates a multi-dimensional reputation model including peer feedback, transaction history, device security, and user’s behavior, and introduces watchdogs to enhance reliability. The model is service-agnostic and focuses on transparency and auditability, but does not implement advanced privacy mechanisms or support inactivity-triggered reputation.

The integration of cryptographic privacy and efficient reputation management is seen in Cheng et al. [12], who proposed PPRM, a lightweight vehicular crowdsensing protocol using homomorphic encryption and zero-knowledge proofs. It addressed location privacy, identity privacy, sensing data privacy, and reputation value privacy while reducing computation and communication overheads of vehicles. Their batch feedback mechanisms are efficient, but the reliance on a centralized reputation center and lack of inactivity penalties limits both decentralization and adaptability.

Efforts to address vehicular and high-mobility settings have led to models such as VANETSecure [22], which introduces a double-layer blockchain (event and reputation chains). This dual-chain approach marks an important step towards scalable and robust reputation management. The reputation scheme features rapid isolation of malicious actors using Bayesian direct/indirect trust, historical decay, and extensible social factors. Yet, the model assumes that RSUs (road-side units) and TA (trusted authority) are never compromised, an unrealistic assumption for critical ITS deployments.

Focusing on data quality and fairness in blockchain-based MCS, specifically in the Human-Centric Sensing (HCS) context, Banti and Louta [16] introduced smart contracts for task assignment, quality evaluation, and reputation management. They distinguished between intentional and unintentional low-quality contributions and implemented a forgiveness mechanism for consistently improved users. They also incorporated witness-based feedback to provide a more robust evaluation of participant behavior. This system automates key processes via smart contracts and leverages IPFS for data offloading. However, the approach does not penalize inactivity and operates all processes on a single public blockchain without advanced privacy or modular extensibility.

Table 1 presents a comparative analysis of the reviewed works alongside our proposed framework. Although previous works have made significant progress in penalizing low-quality contributions, they generally lack comprehensive mechanisms for dynamic reputation that incorporate inactivity decay while simultaneously preserving privacy. While frameworks like VANETSecure [22] utilize dual blockchains for the separate storage of events and reputation to improve data integrity and resilience against malicious behaviors, they fail to account for user dynamics. Specifically, they do not penalize inactive or rarely interacting participants through dynamic reputation reduction. As highlighted in Table 1, RBCrowd addresses this gap by integrating an assessment of inactivity as a core reputation factor. This distinction is critical for preventing reputation hoarding, where a participant maintains a high trust score despite long-term inactivity, potentially exploiting this outdated credibility to manipulate future task allocations or data validation processes.

Table 1. Comparative nalysis of RBCrowd and related work.

Ref	Context of Application	Privacy Technique	Protection Against	Reputation Factors	Assessment Bad Activity	Assessment of Inactivity	Extensibility Formula
[11]	Blockchain- based MCS	Additive secret sharing	False-data injection, curious servers, collusion attacks	Data-distortion, data-consistency, local-rating, contextual factors	Yes	No	Yes
[19]	Wireless Sensor Networks	-	On–off, selective forwarding, collusion attacks	Direct trust, indirect trust, entropy, confidence factor	Yes	No	No
[20]	Crowdsourcing for IoT	Cross-layer, pseudo-ID	Malicious worker/ fog, tampering, collusion attacks	Accuracy, integrity, timeliness, historical rep.	Yes	No	No
[21]	P2P resource sharing over blockchain	-	Malicious/dynamic peer, bad-mouthing, vulnerable devices	Feedback, transactions, device security, user-behavior.	Yes	No	Yes
[12]	Vehicular MCS	Multi-layer cryptography	Inference, Sybil, pollution, identity linkage attacks	Three-factor TFRU: group size, forgetting factor, group weight	Yes	No	No
[22]	VANET	Pseudonym and consortium blockchain	Direct, on–off, collusion, Sybil, and false data	Multi-factor Bayesian direct/indirect trust, historic reputation, social score	Yes	No	Yes
[16]	Blockchain- based HCS/ MCS	-	Malicious/on–off attacks, tampering, feedback bias	Data quality, intentio nal/unintentional errors, historical rep.	Yes	No	No
Our work	Blockchain- based MCS	Dual blockchain (Public + Consortium)	On–off attacks, Malicious validators, collusion, identity linkage attacks	Validators’ feedback, data consistency, contextual alignment, task completion rate, contribution frequency	Yes	Yes	Yes

To the best of our knowledge, our framework is the first fully decentralized dual-chain architecture that integrates a dynamic reputation-weighted scheme with robust privacy controls through blockchain storage separation. The approach represents a significant advancement in the security, fairness, and reliability of MCS systems, but it also guarantees that the reputation scores stay updated and represent the real engagement of participants. By partitioning data and reputation into independent chains, the system mitigates the risk of profiling attacks while ensuring that reputation scores remain dynamic and accurately reflect the real-time engagement and contributions of participants.

3. System Model

In this section, we define the RBCrowd architecture, the potential threat model, the design objectives, and the detailed system workflow. The main notations used in this article are listed in Table 2.

Table 2. Some important notation involved in RBCrowd.

Notation	Definition
$i,W$	Worker, the set of workers
$v,V$	Validator, the set of validators
$f_{v\to i}$	i’s quality feedback assigned by v
$d_i$	Sensing data
U	Aggregate reputation of all workers in a task
$f,F$	Contextual factor, the set of factors
$v_f$	Score of a contextual factor f
$w_f$	Assigned weight to a contextual factor f
$R_i^{old}$	i’s reputation score prior to the current update
$S_i$	The number of sensing task performed by i
$\Delta t_{max}$	The maximum tolerable inactivity window
$\overline{\Delta t_i}$	The average inter-arrival time between successive contributions of i
$\beta$	Decay parameter in CF factor
${\gamma }_1$, ${\gamma }_2$, ${\gamma }_3$, ${\gamma }_4$, ${\gamma }_5$	Weights for factors; VF, DC, CA, TCR, CF
$\lambda$	Growth rate parameter in Gompertz function
$\Delta t_i$	Time of inactivity
$\alpha$	Decay parameter in inactivity update
$R_i$	i’s reputation score

3.1. Overview of RBCrowd Architecture

Figure 1 illustrates the architecture of RBCrowd, a decentralized MCS designed to ensure trust and privacy through a dual-blockchain model. A fundamental distinction of this architecture is no central server or trusted third-party intermediary. In traditional MCS, a central server typically controls task assignment, data validation, and payment; however, RBCrowd distributes these roles across five key entities to eliminate any single point of failure: Task Requesters, Workers, Validators, the Sensing Chain (SC), the Reputation Chain (RC), and the InterPlanetary File System (IPFS). Each component plays a distinct role:

Figure 1. The RBCrowd architecture.

• Task Requester (TR): The TR initiates the sensing process to collect specific information by publishing sensing tasks on the SC. Each task contains detailed specifications, including data requirements, quality thresholds, budget, and deadlines.
• Worker: A participant who performs sensing tasks using the sensors of their mobile devices to earn rewards. Their reputation score evolves based on the quality and frequency of their contributions, and reflects their past behavior and is considered in the task assignment process.
• Validator: Unlike existing works that delegate data validation to a centralized entity [11,16] or a fixed set of nodes [21], we introduce a novel worker-driven validation. Validators are dynamically selected from the worker pool based on specific criteria such as reputation and past reliability. They evaluate the quality and authenticity of data submitted by workers to earn a reward.
• Sensing Chain (SC): SC is a public blockchain that handles the life cycle of crowdsensing tasks, including task publication, data submission, and payment distribution. It ensures all interactions are transparent and tamper-proof.
• Reputation Chain (RC): RC is a consortium blockchain dedicated to manage reputation-related processes. It stores encrypted reputation records, selects validators, and updates reputation scores based on contribution quality and level of activity over time.
• IPFS: We use IPFS as an off-chain storage system to avoid the high costs associated with storing raw data on the main chain. Workers send their collected data to IPFS, which generates a unique content identifier (CID). Only the CID is stored on the main chain SC, which ensures data integrity and traceability while preserving storage scalability and privacy.

3.2. Threat Model

In RBCrowd, we assume an open participation model, where any user with a valid certificate issued by a trusted certificate authority [23] can register in the system as a worker, validator, or task requester. Although their digital identity is verified, that does not guarantee honest behavior. Therefore, we consider a semi-trusted environment in which any participant can engage in strategic, opportunistic, or malicious behavior. To ensure realistic security analysis, we assume that the proportion of malicious contributors does not exceed 40% of the total participants. This threshold aligns with commonly accepted assumptions in decentralized systems, where the majority of nodes are expected to behave honestly. We consider the following potential threat scenarios:

• Malicious workers: Some workers may try to maximize their profits and reputation while minimizing their effort. A common strategy is to use the on–off attack, where a worker may initially behave honestly to build a reputation, then submit falsified or low-quality data.
• Malicious Validators: Malicious validators may collude to unfairly boost or demote other participants. This can lead to biased reputation updates.
• Curious users: Honest but curious participants can exploit publicly available data (metadata, timestamps, location, and blockchain logs) to infer sensitive information about users. This raises concerns about privacy and identity disclosure.

3.3. Design Goals

To address the threats discussed above, RBCrowd is designed with the following objectives:

• Resilience: Implement a reputation-weighted feedback mechanism in which validator input is scaled according to their reputation scores;
• Dynamic: Support both task-driven and inactivity-triggered reputation updates, ensuring that scores reflect not only contribution quality but also sustained engagement over time;
• Transparent: Execute all reputation-related processes, including validator selection, data validation, and reputation updates, through smart contracts deployed on the blockchain;
• Unlinkable: Protect user identity and behavioral privacy by storing only aggregated or anonymized scores on the consortium RC, while the public SC exposes only the task;
• Decentralization: Eliminate any central entities and single points of control, ensuring that RBCrowd remains functional and secure even if some nodes are compromised.

3.4. Operational Workflow

This subsection details the RBCrowd workflow. It highlights how several entities interact via three smart contracts [24]: the User Management Smart Contract (UMSC), which manages user registration, authentication, and access control; the Task Management Smart Contract (TMSC), responsible for posting and assigning tasks, as well as processing submissions; and the Reputation Update Smart Contract (RUSC), which manages validator selection and reputation updates. Figure 2 illustrates the interactions between these smart contracts and their integration with the blockchain layers. The end-to-end process is shown in more detail in Figure 3, which is divided into four steps:

Figure 2. The RBCrowd smart contract architecture.

Figure 3. The RBCrowd Operational Workflow.

Registration phase: Through the UMSC, task requesters register on the SC using their key pairs, and workers (validators) register on the RC. This separation ensures the confidentiality of worker identities in the public ledger, thus limiting the risks of profile linkage and inference attacks. Upon registration, each worker is assigned an initial reputation score of 0.5, reflecting a state of complete uncertainty, with neither trust nor distrust. This neutral starting point avoids any initial exclusionary bias for new participants while preserving accumulated advantages of elder contributors.

Sensing process: A task requester submits the details of their task to the SC via TMSC. They specify information such as the data type, quality requirements, reputation threshold, and deadline. Once published, the task is broadcast across the network, allowing workers to discover it in the list of available tasks. Workers consider the task requirements, and if interested they submit their bids. Based on these submissions, a selection mechanism is implemented to identify the most suitable workers by verifying their reputation proofs on the RC, although the selection algorithm is not discussed in this article. Selected workers then confirm their participation by making a deposit and proceed to execute the assigned sensing task after they submit the collected data to the IPFS. Upon submission, the IPFS generates a unique CID, which is then registered on the SC via the TMSC. When the TR needs to access the results, the CID is retrieved from the blockchain, enabling secure and private access to the data.

Reputation update on contribution: Once the collected data has been submitted, the system triggers the RUSC, which initiates the reputation update process through the selection of validators. To ensure a decentralized and reliable evaluation, validators are dynamically selected from the worker pool based on a minimum reputation threshold, ensuring that only proven participants perform validation. While validators can be selected using various strategies, such as random sampling, proximity-based selection, or a reputation-weighted approach, the specific algorithmic choice is dependent on the application’s requirements and is beyond the scope of this paper. These validators are then tasked with evaluating the submitted data and generating feedback scores (+1 for valid, $-1$ for invalid). After validation, the RUSC recalculates the workers’ reputation score based on five factors: validator feedback (VF), data consistency (DC), contextual alignment (CA), task completion rate (TCR), and contribution frequency (CF). The formulation of these factors is detailed in Section IV. The new reputation score is then encrypted and stored on the RC, thus preventing any reputation leakage. Once the RUSC has issued a valid proof of update, the TMSC on SC atomically releases the reward and refunds the deposits.

Reputation update on inactivity: At the end of each fixed time window $\Delta t_{max}$ (e.g., 30 days), the RUSC performs a global scan of all workers to identify inactive participants who have not participated in any task during the current interval. For each inactive worker, the reputation score is attenuated using a time-based exponential decay function, as formally defined in Section IV. By gradually reducing the scores of inactive users, the system limits the risk of “build-and-quit” behavior, where a user builds a strong reputation and later exploits it without continued participation.

4. RBCrowd: Reputation Management Scheme

In RBCrowd, worker reputation is dynamically updated through a two-phase mechanism that captures both contribution quality and frequency. We evaluate trustworthiness during active contributions using a multi-factor reputation model and a temporal decay during inactivity.

4.1. Reputation Update on Contribution

In this phase, the reputation score of a worker i is updated after each task based on five factors: (1) validator feedback, which captures the quality of a worker’s contributions as assessed by peer validators; (2) data consistency, which measures the degree to which the worker’s submitted data aligns with the collective consensus; (3) contextual alignment, which evaluates the coherence between the submitted data and the task-specific metadata; (4) task completion rate, which reflects the ratio of successfully completed tasks over the total number of tasks participated in; and (5) contribution frequency, which reflects the worker’s level of sustained participation over time.

4.1.1. Trust Factors

• Validators’ feedback (VF)

The validation feedback score serves as a measure to assess a worker’s reliability based on the evaluations of their peer validators. After a task is completed, the data submitted by worker i is evaluated by a set of selected validators V. Each validator $v\in V$ assigns a binary feedback score $f_{v\to i}\in -1,+1$, reflecting their satisfaction with the quality and consistency of the submitted data. To ensure that most reliable validators have greater influence, each score is weighted by validator’s reputation $R_v$. We first define worker i’s raw weighted score as follows:

$${RawVF}_i=\sum _{v\in V}{R}_v\ast f_{v\to i},$$

(1)

To eliminate the effect of negative cumulative feedback, the value is thresholded at 0:

$$RawV{F}_i=\left\{\begin{array}{cc}0,\hfill & \mathrm{if}RawV{F}_i<0\hfill \\ RawV{F}_i,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(2)

Then, the validator feedback score ${VF}_i$ is normalized across all workers W involved in the task to obtain a value between 0 and 1:

$${VF}_i={\displaystyle \frac{RawVF\left(i\right)}{{\sum }_{k\in W}RawVF\left(k\right)}}$$

(3)

This formulation ensures that feedback is both trusted-weighted and relatively scaled within a task context, enabling meaningful comparison across workers with varying validator sets. Similar reputation-weighted schemes have been widely used in trust systems to mitigate biased or collusive ratings, as seen in [25,26].

• Data consistency (DC)

Data consistency quantifies the similarity between a worker i’s submission $d_i$ and those $d_k$ of other workers $k\in W$ on the same task. It identifies whether the worker’s submission is consistent or conflicting with the collective. For each pair of submissions $(d_i,d_k)wherek\ne i$, we compute a similarity score $sim(d_i,d_k)\in [-1,1]$, where 1 indicates identical data and $-1$ indicates completely conflicting data. The data consistency for worker i is the average of these pairwise similarities, weighted by a dynamic adjustment metric that takes into account the reputation of all participants:

$${DC}_i={\displaystyle \frac{1}{\left|W\right|-1}}\sum _{k\in Wk\ne i}sim(di,dk)\times (1-e^{-{\displaystyle \frac{U}{\left|W\right|}}})$$

(4)

where $U={\sum }_{k\in W}{R}_k$ represents the aggregate reputation of all participants in the task. The adjustment factor $1-e^{-{\displaystyle \frac{U}{\left|W\right|}}}$ is a critical security feature that scales the importance of group consensus based on the collective reliability of the participants. The system reinforces trust based on credible peers: if a task is performed by high-reputation workers (high U), the consistency factor $D{C}_i$ carries significant weight in the update. Conversely, if the task is dominated by new or low-reputation participants (low U), the exponential term reduces the influence of the consensus, thereby protecting honest workers from potential collusion or Sybil majorities. This method is consistent with Quality of Information (QoI) models that require aggregating similarity measures to evaluate data reliability [27].

To calculate the similarity score $sim(d_i,d_k)$, various similarity methods can be applied depending on the data type, including (1) Perceptual Hashing (pHash) [28] for image data, which generates compact hash vectors where similarity is inferred from Hamming distance between hashes; (2) CNN-based embedding [29,30] compared using cosine similarity [7] for high-dimensional or unstructured data such as images or sensor streams; and (3) statistical comparisons (e.g., z-score deviation) or clustering-based methods (e.g., k-means, DBSCAN) [31] to evaluate consistency between structured numerical data.

• Contextual Alignment (CA)

The contextual alignment factor evaluates the correspondence between submitted data matches the task-specific contextual attributes, such as location, time, device information, and semantic tags. Contributions captured in the correct location, within the specified time window, and with consistent semantic tags are considered more trustworthy. For example, a submission labeled “busy road” yet captured in a rural area would exhibit low semantic alignment. The type and importance of these contextual factors may vary depending on the operational scenario. Each factor $f\in F$ evaluated through a normalized score $v_f\left(i\right)\in [0,1]$. Each is assigned a corresponding weight $w_f$, reflecting its relative importance with ${\sum }_{f\in F}{w}_f=1$. The contextual alignment score for worker i is computed as

$${CA}_i=\sum _{f\in F}{w}_f\ast v_f\left(i\right)$$

(5)

This weighted sum allows the system to flexibly integrate multiple contextual factors, regarding the system requirements. Context-aware trust models in mobile sensing often rely on spatiotemporal and semantic metadata to detect low-quality or malicious submissions [32].

• Task Completion Rate (TCR)

The task completion rate reflects the ratio of successfully completed tasks and the total number of sensing tasks in which a worker has participated. The quality of each task (via $DC$ and $CA$) and the worker’s historical reputation is considered to determine the rate of successful completion. This factor is essential for assessing the reliability, consistency, and long-term engagement of workers. A high task completion rate indicates that the worker regularly produces valid contributions. Formally, the task completion rate is defined as

$${TCR}_i={\displaystyle \frac{1}{|S_i|}}\sum _{k\in S_i}({DC}_i^k\ast {CA}_i^k\ast \sqrt{R_i^{old}})$$

(6)

where $S_i$ is the set of sensing tasks conducted by the worker i, and $R_i^{old}$ represents the worker’s reputation score prior to the current update. The inclusion of $\sqrt{R_i^{old}}$ introduces a diminishing-return effect, which rewards consistent engagement while preventing runaway reputation inflation. This design is consistent with prior research [33], which emphasizes the importance of incorporating both recent behavior and historical trust to defend against on–off attacks and ensure fair long-term evaluation. Since negative values of $TCR$ reflect invalid contributions, they are clipped at 0, while the positive values are capped at 1 to ensure consistency with other factors. The normalized task completion rate is defined as $max\{0,{TCR}_i\}$.

• Contribution frequency (CF)

The contribution frequency factor quantifies how consistently a worker contributes over time. It designed to reward regular and sustained participation while penalizing prolonged inactivity, thereby reflecting the worker’s ongoing commitment. Let $\Delta t_{max}$ denote the system-defined maximum tolerable inactivity window (e.g., 30 days), and let $\beta$ be a decay parameter that controls the sensitivity of inactivity. Define $\Delta t_i$ as the average inter-arrival time between successive contributions made by a worker i, it can be calculated as in (7). The contribution frequency factor is defined in (8).

$$\overline{\Delta t_i}={\displaystyle \frac{1}{n-1}}\sum _{k=2}^n(t_k-t_{k-1})$$

(7)

$${CF}_i=e^{-\beta {\displaystyle \frac{\overline{\Delta t_i}}{\Delta t_{max}}}}$$

(8)

In this formulation, workers with frequent contributions (small $\overline{\Delta t_i}$) receive higher scores, and workers with long inactivity gaps (large $\overline{\Delta t_i}$) receive lower scores. This design ensures that trust in a worker reflects also the recency of their engagement, encouraging continuous engagement and discouraging opportunistic behavior.

4.1.2. Reputation Function

The overall reputation score $R_i$ is computed as a weighted aggregation of the previously defined trust factors as in (9), where ${{\sum }_{k=1}^5\gamma }_k=1$.

$$\widehat{R_i}={\gamma }_{1}V{F}_i+{\gamma }_{2}D{C}_i+{\gamma }_{3}C{A}_i+{\gamma }_{4}TC{R}_i+{\gamma }_{5}C{F}_i$$

(9)

To prevent uncontrolled growth in reputation scores and ensure diminishing returns for repeated contributions, the final score is passed through the Gompertz function [34], a sigmoidal model widely used in trust-aware systems. This function models saturating growth behavior, allowing new or moderately active users to build trust quickly, while limiting the impact of excessive contributions by very active users, thus preventing runaway inflation in reputation. The final reputation score is adjusted as in (10), where $\lambda >0$ defines the growth rate.

$$R_i=e^{-e^{-\lambda {\widehat{R}}_i}}$$

(10)

4.2. Reputation Update on Inactivity

In RBCrowd, the reputation system is designed not only to assess the quality of active contributions but also to reflect the temporal engagement of each participant. To this end, we define a second phase in our reputation management scheme that applies to workers who were inactive within a predefined time threshold. This phase ensures that reputation scores decay appropriately over periods of inactivity, maintaining a dynamic reputation scheme. Let $\Delta t_{max}$ represent the maximum tolerated inactivity period. A worker i is considered inactive if they have made no contributions during the $\Delta t_{max}$ window. In this case, their reputation is updated using a time-based exponential decay function to penalize this disengagement. Let $t_{last}$ denote the timestamp of worker i’s most recent contribution, and $t_{now}$ be the current system time (e.g., the end of the current month). The time since last contribution is computed as $\Delta t_i=t_{now}-t_{last}$. The updated reputation score is calculated using the following decay formula:

$$R_i=R_i^{old}\ast e^{-\alpha {\displaystyle \frac{\Delta t_i}{\Delta t_{max}}}}$$

(11)

where $\alpha$ is the decay rate parameter, which controls how quickly trust decreases over time. This equation ensures that workers who remain inactive for an entire $\Delta t_{max}$ receive a moderate penalty to their reputation score. This decay function is evaluated periodically at the end of each $\Delta t_{max}$ interval for all workers. If a user has contributed within that period, the system uses the on-contribution update mechanism instead. If no new data has been submitted, the decay is automatically applied. This design ensures that reputation scores remain responsive and current. Crucially, this update is performed within the RC, ensuring that the penalty process itself does not leak behavioral patterns to the public SC.

5. Experimental Evaluation

This section presents the evaluation of the proposed RBCrowd framework from two perspectives: security and theoretical analysis, and simulation analysis. To demonstrate how our framework mitigates potential attacks, we first provide a theoretical security analysis. Then, we conduct simulation experiments under different MCS scenarios to evaluate the effectiveness of the proposed reputation scheme in dynamically adapting to worker behavior.

5.1. Security Analysis

In this subsection, we illustrate the security advantages of RBCrowd and its reliability against threat models.

• RBCrowd can effectively resist inactive and malicious workers.
  Malicious workers can submit falsified or low-quality data to compromise the system and receive more profits. In our proposed RBCrowd, these workers cannot maintain a high reputation over time, as the dynamic and weighted reputation update features penalize dishonesty. Furthermore, we assumed that the number of malicious contributors does not exceed 40% of the total number of contributors. Therefore, more than half of the workers are honest and provide low feedback when compromised data is submitted. On the other hand, the reputation update on inactivity ensures that inactive or periodic workers do not attain high reputation scores. This provides a dynamic and real reputation score that reflects the current level of worker engagement.
• On–off attackers incur significant penalties that contradict their objectives.
  On–off attackers initially behave honestly to build a high reputation, then switch to malicious behavior. However, under our RBCrowd, they quickly lose credibility due to the strong weighting of quality-based factors. Since our reputation scheme is based on past and recent behaviors, with a greater proportion for the current contribution, malicious actions have an immediate and significant impact. As a result, workers are discouraged from submitting low-quality data, as doing so drastically decreases their reputation score, requiring substantial effort and many high-quality contributions to recover. This design ensures that building a reputation is unsustainable and that long-term trust can only be achieved through consistent, honest participation.
• RBCrowd mitigates validator collusion through reputation-weighted feedback.
  Malicious validators may collude to unfairly influence a worker’s reputation. In RBCrowd, however, their influence is limited by their own reputation score, which becomes dynamically based on the consistency of their behavior. Furthermore, our reputation scheme does not rely solely on validator feedback but incorporates multiple quality factors into the reputation update process. This design significantly reduces the implication of collusion, while preserving the fairness and objectivity of data evaluation.
• RBCrowd enhances privacy and mitigates linkability risks through dual-blockchain separation.
  In some existing blockchain-based MCS systems, simultaneously storing collected data and reputation information on the same chain exposes users to profile linkage attacks. Adversaries can correlate contributions, metadata, timestamps, and reputation scores to infer sensitive information. RBCrowd addresses this challenge by separating collected data and reputation information into two distinct blockchains. The sensing process is securely performed on the SC, while reputation updates are managed on the RC, with interactions linked only by pseudonymous identifiers. This architectural separation mitigates linkage attacks and preserves linking between identity, data, and reputation, which enhances user privacy without compromising accountability.
• RBCrowd secures data integrity and confidentiality through off-chain IPFS storage.
  To enhance privacy, RBCrowd uses IPFS to store raw collected data off-chain, and only CIDs are stored on the SC. This ensures data integrity and prevents the disclosure of sensitive information on the public ledger. This approach also reduces the blockchain load and prevents linking users to their raw data, which provides an additional layer of privacy preservation.

5.2. Simulation Analysis

5.2.1. Simulation Settings

In this section, we implement a simulation model for the proposed RBCrowd framework using NetLogo environment [35], an agent-based modeling software designed to simulate and analyze large-scale networks [36]. In the MCS context, NetLogo enables us to emulate the behavior of multiple workers performing sensing tasks over time while capturing the evolution of their reputation. While the technical performance of the blockchain infrastructure, including transaction latency, gas costs, and storage overhead, was verified in our previous study [10], the experiments in this work are specifically designed to evaluate the reputation update scheme.

The simulation is designed as a cycle-based model, with each cycle representing a data collection phase. In each cycle, the TR publishes sensing tasks, workers decide whether to participate, and validators provide feedback on the submitted data. This design allows us to evaluate the influence of different parameters on the overall system performance in various participation and inactivity scenarios. To reflect realistic behaviors, we define four worker categories, each representing a distinct participation strategy:

• Honest workers, who always provide valid sensing data and contribute regularly;
• Malicious workers, who intentionally submit low-quality or falsified data in order to manipulate the system;
• On–off attackers, who act strategically and honestly for a period of time to build their reputation, then turn to malicious behavior;
• Inactive workers, who contribute initially but later withdraw for varying periods create a challenge to outdated reputation scores.

To evaluate RBCrowd’s performance, we simulated over 300 cycles with a community of 100 workers, composed of a mix of honest workers, malicious workers, on–off attackers, and inactive workers. Each simulation setup was repeated multiple times randomly to ensure the statistical reliability of the results. All workers were initialized with a reputation score of 0.5, and this score was dynamically updated each cycle using the proposed two-phase scheme.

5.2.2. Parameter Sensitivity Analysis

The proposed reputation management scheme relies on several equations with parameters that must be reasonably configured according to the system setup, while also examining their impact on the reputation update. The key parameters to be adjusted in our reputation scheme are $\lambda ,\beta ,\alpha$, and the weights ${\gamma }_k$. First, we analyze the impact of $\lambda$, the growth rate of the Gompertz function, to determine the appropriate value for controlling the convergence speed of the reputation updates on contributions. Thereby, we randomly select an honest worker and fix $\beta =1$, with all weights set equally $({\gamma }_1={\gamma }_2={\gamma }_3={\gamma }_4={\gamma }_5=0.2)$, to isolate and analyze the effect of $\lambda$ on the convergence speed of reputation updates. As illustrated in Figure 4, a larger $\lambda$ results in faster convergence of users’ reputation to 1 within approximately 60 sensing tasks. However, $\lambda$ must be carefully tuned, as values that are too large may lead to premature convergence, while values that are too small may cause slow convergence. Based on practical system considerations, we set $\lambda =0.1$ in the following experiments. This balance ensures that trust is built at a rate that discourages temporary honest behavior while rewarding long-term consistency.

Figure 4. The impact of different parameters on reputation score. (a) The impact of Gompertz function growth $\lambda$. (b) The impact of decay parameter $\beta$ in CF. (c) The impact of decay parameter $\alpha$ in inactivity.

Next, we analyze the sensitivity of $\beta$, a decay parameter that controls the $CF$ factor. To this end, we randomly select two workers with different activity levels within $\Delta t_{max}$. The first, worker A, is an active participant, with 21 contributions, while the second, worker B, is relatively inactive, with only 4 contributions. Figure 4 illustrates the impact of varying $\beta$ values on the $CF$ factor over a time window of $\Delta t_{max}=30$ days. For worker A, $\beta$ mainly impacts the rate at which small fluctuations in contribution frequency are penalized, while overall $CF$ remains relatively stable. For worker B, smaller $\beta$ values results in more gradual decay, allowing the worker to retain a higher $CF$ score despite inactivity. Overall, these results confirm that careful tuning of $\beta$ is essential: setting $\beta$ too high may overly penalize short inactivity, while setting it too low may fail to discourage irregular participation. Based on this trade-off, we set $\beta =3$ in the following experiments to balance fairness and robustness.

In the same way, we evaluate the impact of $\alpha$, a decay parameter that determines how quickly a worker’s reputation decreases during periods of inactivity. For this simulation, we consider a single worker who contributes actively for the first 40 days before becoming inactive. Figure 4 illustrates the evolution of reputation over 220 days for different values of $\alpha$. Higher $\alpha$ values result in a faster decay, while lower $\alpha$ values allow the reputation to remain relatively high for a longer period despite inactivity. These results highlight the importance of selecting an appropriate $\alpha$ value to balance fairness and responsiveness. For the subsequent experiments, we set $\alpha =4$ to achieve stronger penalization in the case of prolonged inactivity.

Finally, we analyze the sensitivity of the weights parameters ${\gamma }_k$, to represent the proportion of each factor in the reputation update. The reputation scheme based on contribution is composed of two parts: (i) the evaluation of the current contribution quality, calculated based on three factors: $VF,DC,CA$; and (ii) the assessment of long-term behavior, represented by two factors: $TCR$, $CF$. These weights must satisfy the condition ${{\sum }_{k=1}^5\gamma }_k=1$, ensuring a normalized contribution of each factor to the global reputation score. To investigate the effect of individual ${\gamma }_k$ values, we vary one parameter at a time while keeping the others equal and observe the resulting evolution of workers’ reputation.

From Section 4, we may infer that all parameters are in the range $[0,1]$, except $DC$, which can be negative $[-1,1]$. Thus, we start by analyzing ${\gamma }_2$, considering that $DC$ will decrease constantly the reputation of malicious workers. To illustrate how ${\gamma }_2$ affects various worker types, we arbitrarily choose two individuals: an honest worker and a malicious worker. As illustrated in Figure 5, higher ${\gamma }_2$ accelerates convergence of reputation scores to 1 for honest workers. For malicious workers, increasing ${\gamma }_2$ amplifies its influence in penalizing malicious behavior. In low ${\gamma }_2$ values $(0.1,0.15)$, the reputation of the malicious worker converges to 0 after 80 sensing tasks, indicating weak sensitivity to inconsistency data, while a higher ${\gamma }_2$ can consistently converge. Therefore, to prevent malicious workers from being unidentified by reputation score changes, consider $DC$ as a significant factor and set ${\gamma }_2$ appropriately.

Figure 5. The impact of different weights on reputation score. (a) The weight ${\gamma }_1$. (b) The weight ${\gamma }_2$. (c) The weight ${\gamma }_3$. (d) The weight ${\gamma }_4$. (e) The weight ${\gamma }_5$.

For parameter ${\gamma }_1$, the weight of $VF$ reflects the extent to which a worker’s contribution is validated by other participants. Figure 5 shows the effect of different ${\gamma }_1$ values on both honest and malicious workers. For honest workers, larger ${\gamma }_1$ values $(0.4,0.3)$ accelerate convergence toward reputation $=1$, since verified contributions are rewarded more strongly. Conversely, for malicious workers, ${\gamma }_1$ amplifies the speed at which their reputation decreases, as invalid contributions are consistently penalized. When ${\gamma }_1$ is too small $\left(0.1\right)$, the reputation of malicious workers converges slowly toward 0, weakening the system’s ability to detect and penalize misbehavior.

In the same way, we evaluate the weight ${\gamma }_3$ in the reputation update; its effect is similar to ${\gamma }_1$. As shown in Figure 5, larger ${\gamma }_3$ values similarly slow down convergence for honest workers, since more weight is shifted toward this single dimension. Therefore, ${\gamma }_3$ and ${\gamma }_1$ should be carefully balanced with $DC$ to avoid over-reliance on a single accuracy metric. In the following experiments, we set ${\gamma }_1={\gamma }_3=0.2$.

Then, we observe the change of reputation score to analyze the sensitivity of ${\gamma }_4$. As illustrated in Figure 5, increasing ${\gamma }_4$ accelerates the convergence of honest workers with stable participation toward higher reputation values, whereas malicious workers experience a sharper decline in their reputation. This highlights the importance of $TCR$ as a behavioral metric to reinforce long-term reliability. In the same way, we examine the impact of ${\gamma }_5$ in reputation evolution, which quantifies the regularity of participation across time. Similarly to ${\gamma }_4$, ${\gamma }_5$ exhibits the property that the larger it is, the higher the reputation score converges to 1, as illustrated in Figure 5. However, if set too high, it may over-penalize legitimate but less frequent participants.

To conclude, Table 3 consolidates the values of all parameters fixed throughout the sensitivity analysis, providing a concise overview of the experimental configuration.

Table 3. Simulation parameters.

Parameter	Value
$\lambda$	$0.1$
$\beta$	3
$\alpha$	4
${\gamma }_1$, ${\gamma }_3$	$0.2$
${\gamma }_2$	$0.3$
${\gamma }_4$, ${\gamma }_5$	$0.15$
$\Delta t_{max}$	30 days
Initial reputation $R_0$	$0.5$
Number of workers	100
Number of malicious workers	10–40%
Number of cycles	300

5.2.3. Robustness in Different Scenarios

In this subsection, we analyze the changes in reputation scores under different strategies to examine how they reflect worker behaviors.

Case 1.  Honest workers.

For honest workers, the reputation score changes according to the rate of malicious workers in the system. We assume that the proportion of malicious workers is less than 40%, as shown in Table 3. The reputation score slowly increases to ensure that workers remain aware of the risk to losing accumulated scores after a long period of good behavior. The simulation results are shown in Figure 6. When the rate of malicious worker is low, the reputation score steadily increases and converges to 1, since validators feedback and data quality are reliable. As the number of malicious workers increases, the reputation score grows more slowly because honest workers receive less support. Therefore, RBCrowd demonstrates better precision in gradually accumulating reputation scores and can remain effective even under higher malicious worker rates.

Figure 6. The reputation score changes in different scenarios: (a) Honest workers. (b) Malicious workers. (c) On–off attackers. (d) Inactive workers.

Case 2.  Malicious workers.

Figure 6 presents the changes in the reputation scores of malicious workers, which decrease as the rate of malicious participation in the system increases. When the percentage of malicious workers is relatively low, the reputation score decreases gradually over sensing tasks. However, as the proportion of malicious workers increases, the reputation score reduces more rapidly, approaching zero more quickly. This indicates that malicious workers cannot maintain a high reputation for long, since validators’ feedback and the impact of poor-quality data reduce their scores. Hence, RBCrowd effectively penalizes malicious behaviors by ensuring that their accumulated reputation diminishes over time, with faster decreases observed at higher malicious worker rates.

Case 3.  On–off attackers.

On–off attacks pose a critical problem for reputation management systems, as attackers can exploit their accumulated reputation to gain access to sensing and validation tasks. Figure 6 illustrates the reputation evolution of an on–off attacker. The worker initially behaves honestly during the first 20 sensing tasks to accumulate a good reputation score, then acts maliciously during the next 40 tasks before reverting to honest behavior for the rest of the simulation. The results show that the attacker can initially accumulate reputation by acting well, but once malicious behavior occurs, their reputation score decreases sharply, illustrating the system’s sensitivity to dishonest contributions. Even when the attacker restarts honest behavior, reputation recovery is much slower than the initial increase due to the impact of behavioral history built into the $TCR$ factor. This prevents attackers from easily regaining trust after malicious action, thus discouraging them from risking their accumulated reputation. Thus, we ensure that reputation loss is significant and that recovery requires a long history of impeccable behavior, which demonstrates RBCrowd’s robustness against on–off attacks.

Case 4.  Inactive workers.

Figure 6 illustrates how contributor reputation scores grow based on their activity level and behavior. All workers begin with an initial score of $0.5$, and their reputation evolves according to their contributions. Honest workers, who contribute regularly, see their reputation gradually increase, converging toward 1 despite some fluctuations due to irregular participation. Honest workers who remain active for a period of time and then become inactive accumulate higher scores during their active phase, after which their reputation stabilizes at the level it had reached before ceasing to contribute. Conversely, malicious contributors experience a decline in reputation, with their scores converging toward 0 over time. Even infrequent participation is enough to lead to a steady loss of reputation, particularly in the case of submitting poor-quality data. This demonstrates that RBCrowd can effectively distinguish between different contributor behaviors: rewarding consistent honesty, preserving the scores of inactive but previously honest contributors, and penalizing malicious participants regardless of their level of activity.

6. Conclusions

In conclusion, we presented RBCrowd, a dynamic framework designed to handle reputation management in mobile crowdsensing without sacrificing fairness or privacy. To protect user anonymity, we devised a dual-blockchain architecture: one chain handles anonymous sensing tasks and data transactions, while a separate chain securely manages worker identities and reputation scores. For storage efficiency, the actual data is kept off-chain via IPFS.

The core of RBCrowd is a multi-factor reputation scheme that rewards consistent, high-quality work. Unlike existing frameworks, our model treats inactivity as a primary trust factor, utilizing an automated decay mechanism to ensure that reputation scores represent real-time engagement. This is achieved through a fine-grained dual-chain separation that provides the first robust solution for privacy-preserving temporal trust management. We assessed the framework’s performance using simulations designed to mirror realistic MCS scenarios. We also performed sensitivity analyses to identify the optimal values for our weighting parameters. Our simulations demonstrate that RBCrowd offers superior protection against internal attacks and functions more effectively than current state-of-the-art solutions.

While RBCrowd demonstrates significant improvements in fairness, privacy, and adaptability to diverse user behaviors, scalability and practical deployment remain important challenges. As future work, we plan to implement a prototype of the framework as a real-world MCS use case, where we will establish concrete mechanisms for data consistency, contextual alignment, and validator selection. This prototype will allow us to evaluate performance under realistic conditions, including network latency, throughput, and large-scale participation. We also plan to integrate advanced privacy-preserving techniques, such as zero-knowledge proof, to strengthen authentication and further mitigate risks of privacy leakage.