Dynamic Decentralized Reputation System from Blockchain and Secure Multiparty Computation

Abstract

In decentralized environments, such as mobile ad hoc networks (MANETs) and wireless sensor networks (WSNs), traditional reputation management systems are not viable due to their dependence on a central authority that is both accessible and trustworthy for all participants. This is particularly challenging in light of the dynamic nature of these networks. To overcome these limitations, our proposed solution utilizes blockchain technology to maintain global reputation information while remaining fully decentralized, and to secure multiparty computation to ensure privacy. Our system is not limited to specific settings, such as buyer/seller or provider/client scenarios, where only a subset of the network are raters while the others are ratees. Instead, it allows all nodes to participate in both rating and being rated. In terms of security, the system maintains feedback privacy in the semi-honest model, even in the presence of up to $n-2$ dishonest parties, while requiring only $O\left(n\right)$ messages and having an $O\left(n\right)$ computation overhead. Furthermore, the adopted techniques enable the system to achieve unique characteristics such as accessibility, consistency, and verifiability, as supported by the security analysis provided.

1. Introduction

The reputation of a party is a metric that reflects the level of trust and confidence that other parties have in it. This metric is derived from the actions and conduct of the party in question, as well as the judgments made by other parties regarding those actions. Depending on the context, a party may be expected to adhere to certain codes of conduct or perform specific actions, and the quality of those actions will be evaluated by other parties, leading to the formation of a rating [1,2]. A party’s reputation can be influenced by a multitude of factors, including its past actions, behavior, and the opinions of others. A strong reputation can be beneficial for a party as it can lead to increased trust and cooperation from other parties, whereas a poor reputation can have the opposite effect. To facilitate the monitoring and evaluation of a party’s reputation, reputation management systems are often utilized, providing a basis for other parties to make informed decisions about their interactions with the party in question.

E-commerce platforms often include built-in reputation systems that gather user feedback on items and sellers. They present this aggregated data to consumers, helping them make decisions about which products to buy and from whom. This type of reputation system is known as a centralized reputation system, which relies on a trusted central authority, such as a market operator (Airbnb, eBay, or Amazon), to provide oversight and ensure the authenticity of the feedback.

However, there are certain contexts where a central authority is not present. This includes decentralized social networks (DSNs), MANETs, peer-to-peer systems (P2P), WSNs, and other types of systems. In such scenarios, traditional centralized reputation systems are not effective. This is where decentralized reputation systems (DRSs) come into play [3,4,5]. These systems are designed to operate without a central authority and instead rely on the collective input of network participants to establish trust and evaluate reputations.

It is worth mentioning that centralized and decentralized reputation systems are two distinct approaches to managing and evaluating reputation within systems or networks.

Centralized reputation systems are characterized by the presence of a central authority, such as a company or organization, that is responsible for collecting, analyzing, and determining reputational scores [2]. This central authority also makes decisions about access or privileges based on those scores. However, this approach can be vulnerable to manipulation or bias due to the reliance on a single source of truth for reputation data.

On the other hand, decentralized reputation systems do not rely on a central authority for managing reputation data [6]. Instead, the reputation data is distributed across a network of individuals or entities, and decisions about access or privileges are made based on consensus among those individuals or entities, which increases the fairness and resilience of those systems, making them less prone to failure or censorship as they have no central point of control.

It is evident that the centralized paradigm does not apply in situations where there is a lack of a central authority. In such scenarios, distributed reputation systems (DRSs) provide an alternative solution. DRSs employ various techniques for the collection and distribution of reputation data [3,4,5]. In (MANETs), for instance, a node can gather reputation information about its peers through previous interactions and use this information to inform its future decisions. When a node has no prior experience with a peer or is new to the network, the conventional approach is to seek out the reputation information of other peers in the network and use it to make decisions regarding interactions with the targeted node.

One of the key considerations in implementing DRSs is feedback privacy [6]. If peers’ feedback is disclosed for any reason, particularly when their identities are publicly known, they may face retaliation attacks and receive low ratings, for example, [7]. Additionally, there is a potential for ratings to be provided for the purpose of reciprocation, with a user giving an unjustified high rating in anticipation of receiving a similar rating in future interactions.

To address the challenges associated with the protection of privacy in decentralized reputation systems, researchers have proposed various privacy-preserving decentralized reputation systems (PDRSs) [6,7,8,9,10]. These systems enable parties to avoid directly transmitting their reputation information to the requesting party and instead employ protocols that allow them to compute reputation as a function of their rating values while maintaining the privacy of these values. The outcome of this computation is then revealed to the requesting party.

However, it should be noted that the reputation information gathered by such systems is typically limited to the users’ direct experiences and recommendations from neighbors and acquaintances, resulting in incomplete and inconsistent reputation data across the network. This raises the question of how to aggregate ratings effectively in a decentralized network and maintain global reputation scores while preserving the ratings’ privacy.

1.1. Contributions

In this paper, we propose an efficient and dynamic decentralized reputation system that maintains global reputation information by integrating secure multiparty computation techniques [11] with blockchain technology [12]. The proposed system guarantees the privacy of individual ratings while making the aggregated reputation scores publicly accessible.

Additionally, we analyze several reputation system models in the literature and develop a general-purpose reputation system that is not restricted to scenarios where nodes are either raters or ratees, such as buyers/sellers or providers/clients. Instead, any participant in the network can function both as a rater and a ratee simultaneously.

Furthermore, we design a blockchain-based architecture that implements the proposed reputation system while reducing the on-chain storage and computation overhead with an off-chain phase. Security analysis demonstrates the reliability of the proposed system.

In contrast to previous works on the subject, the proposed system achieves unique properties such as accessibility, consistency, conservation, and verifiability.

In summary, the main contributions of this paper can be summarized as:

• Propose an efficient and dynamic decentralized reputation system that maintains global reputation scores;
• Develop a general-purpose reputation system that is not restricted to scenarios where nodes are either raters or ratees;
• Design a blockchain-based architecture that reduces the on-chain storage and computation overhead with an off-chain phase;
• Achieve unique properties such as privacy, accessibility, consistency, conservation, and verifiability.

Remarkably, some of the properties mentioned above can be trivial in the context of centralized reputation systems. But in dynamic PDRSs, they are challenging.

1.2. Organization

The rest of the paper is structured as follows: the second section comprises a review of the relevant literature in the field, followed by an introduction of the key components of our system, including any modifications or adaptations made. We also provide definitions for the concepts of trust and reputation, which are vital for the system’s operation, and discuss the security considerations that informed our design choices. The third section offers a comprehensive overview of the system and its various phases. The fourth section presents the results of our testing and evaluation efforts, including the methods used to assess the system’s performance. In addition, the security proof and analysis are included in Appendix A. The conclusion summarizes the main contributions of the paper and identifies potential areas for future research that could build upon the work presented here.

2. Preliminaries

In this section, we first provide an overview of the current state of the art in decentralized reputation systems. We then present an introduction to both blockchain and SMC (Secure Multi-Party Computation), including any modifications or adaptations that have been made, and highlight specific features that are suitable for our proposed use case. Finally, we provide definitions for relevant concepts related to the proposed system and discuss important security considerations.

2.1. Related Works

In PDRSs, there are two primary approaches to ensuring privacy [13]. The first approach prioritizes user anonymity, while the second approach emphasizes feedback confidentiality. The distinction between these two approaches can be summarized as follows [13]:

• The first approach, known as user anonymity-oriented systems, assigns one or more pseudonyms to users that cannot be linked to their true identities to preserve anonymity. These systems allow the users to conduct transactions and provide feedback without hiding it because they are not associated with their true identities.
• The second approach, known as feedback confidentiality-oriented systems, assigns unique pseudonyms to each user, and feedback is kept private. These systems do not aim to conceal the identities of the users providing feedback, but rather to hide the specific feedback values. In theory, these systems should not reveal any information about feedback other than the aggregated reputation.

The current study adopts the second approach as it is more pragmatic and realistic. This is because, in reality, complete anonymity is not always feasible in everyday situations. For instance, on e-commerce platforms, even if anonymity can be maintained online, the exchange of physical goods sold on them may reveal customers’ identities. From this perspective, feedback-confidentiality systems are a more viable option for enabling users to give honest feedback without fear of retaliation.

Most traditional works in the field of PDRSs (e.g., [6,8,9,10]) focus on a scenario where a querying party, denoted as $P_q$, wishes to interact with a target party, denoted as $P_t$, but is uncertain of $P_t$’s trustworthiness. This may be due to a lack of information about $P_t$’s past behavior, or limited or outdated experience with $P_t$. Let $\{P_1^{\left(t\right)},P_2^{\left(t\right)},\dots ,P_N^{\left(t\right)}\}$ represent the set of parties that possess reputation information about $P_t$, referred to as witnesses or source parties. In such cases, $P_q$ can consult a selected subset of source parties, namely $\{P_{i_1}^{\left(t\right)},P_{i_2}^{\left(t\right)},\dots ,P_{i_n}^{\left(t\right)}\}$ ($n\le N$), who will execute a protocol to compute $P_t$’s reputation score securely and then send the result to $P_q$.

In line with this setting, one of the earliest works in the field is presented in [6]. The authors proposed a system that relies on random witness selection and additive secret sharing. The system offers three different levels of security and demonstrates the feasibility of witness selection schemes that produce at least two honest witnesses with high probability. Despite being fully decentralized and suitable for general use, the system is not able to compute and store global reputation scores. Instead, each party in the system must retain its gathered information locally, and reputation is determined solely by feedback from neighboring parties. Additionally, the system demands the exchange of $O\left(n^2\right)$ messages for each reputation request.

The authors of [7,9] expanded upon the work presented in [6] with the k-shares reputation system, which is designed for the semi-honest and malicious adversarial model, respectively. Their system enhances efficiency by reducing communication costs to $O\left(n\right)$ messages. Furthermore, it increases the probability of keeping reputation information private by enabling users to choose witnesses with good reputation scores while avoiding those they do not trust.

The previous systems presented in [6,7,9] are not well-suited for dynamic networks due to a number of limitations. Specifically, in dynamic networks, the number of available source parties, or parties currently participating in the network, may be smaller than in a static network. Furthermore, when a party leaves the network, all of its reputation information becomes inaccessible, as each party stores its information locally. As a result, reputation is likely to be computed with a different set of present parties each time a party requests it, leading to inconsistent and changing reputation information at each request.

To address these challenges, authors in [10] proposed a system that enables parties leaving the network to delegate their reputation information in order to prevent its loss. However, this approach comes with an increase in computation and communication costs and requires the leaving user to divide the entrusted information among a group of users (through secret-sharing) before leaving. Additionally, if a member of the delegation group leaves, the information must be re-delegated, making the recovery and reconstruction of the delegated information more challenging as the number of parties involved increases and the data become fragmented.

Despite the efforts made to prevent the loss of reputation information, it is evident that the previously mentioned solutions remain incapable of computing and storing global reputation scores. These methods rely on users’ direct experiences and recommendations from neighbors and acquaintances, resulting in incomplete and inconsistent reputation data that are primarily shared locally.

To structure the literature review effectively, we assess and classify related works according to the following criteria:

1.

Full Decentralization: Reputation systems that do not depend on central entities for the collection, computation, or dissemination of reputation scores [14]. Instead, the information is distributed among parties, who share it to evaluate the trustworthiness of potential transactional partners.

2.

General-Purpose Reputation Systems: These systems are designed to be utilized in various network environments and are not limited to specific settings such as service providers/consumers in online marketplaces or servers/clients in IoT [6,9,10]. They are flexible enough to adapt to various networks, including P2P, MANETs, or WSNs.

3.

Global Reputation Systems: These systems collect ratings from all over the network and aggregate them into global reputation scores that are accessible to all users across the network [15].

4.

Privacy: refers to the ability of a reputation system to compute and disseminate reputation scores while preserving feedback privacy [7,10].

It is worth noting that many proposed systems in the literature are not general-purpose systems. Rather, they are tailored to specific contexts such as online marketplaces [16,17,18] or the Internet of Things (IoT) [19,20,21,22], where the network is divided into two distinct groups: ratees and raters. In online marketplaces, users are either consumers (raters) or service providers (ratees), while in IoT, they are either server nodes or clients. However, in other contexts, such as P2P networks, MANETs, VANETs, DSNs, and WSNs, users often have to play both the role of a rater and a ratee.

We emphasize that such proposed systems are often too specific or incompatible with fully distributed settings such as P2P networks, MANETs, or WSNs. One example is PrivBox [23], a verifiable reputation system for online marketplaces. It enables consumers to rate retailers and submit their feedback in an encrypted form using homomorphic encryption to a public bulletin board (PBB). The system makes reputation information publicly accessible and verifiable without disclosing the individual ratings. However, the system leaves the reputation computation task to any customer who wishes to compute the reputation of a particular vendor. The system employs zero-knowledge proofs to demonstrate that the ratings are well-formed.

Another example of such a system is PrivRep [24], which builds upon the work presented in [23]. The system utilizes a public bulletin board (PBB) in combination with a reputation engine (RE) to calculate reputation from homomorphically encrypted feedback. The RE is controlled and operated by the marketplace, rather than regular users, and it has the authority to reject feedback deemed untrustworthy. It is evident that the use of two central entities, namely the RE for computation and the PBB for storage, undermines the decentralized nature of the proposed system.

Similarly, the system proposed in [15] for the Social Internet of Things also relies on a PBB. However, the authors mention the possibility of implementing it as a blockchain or a mirrored server, which may address the issue of centralization and enhance the decentralized aspect of the system.

In [17], the authors proposed a blockchain-based cross-platform reputation system for e-commerce, referred to as RepChain. The system interconnects various e-commerce platforms and enables them to share their users’ reputations through a consortium blockchain. While the system is not entirely decentralized, as each platform relies on its centralized entity, the top layer interconnecting platforms are decentralized owing to the use of blockchain technology.

The authors in [25] propose a solution to blockchain usage limitations in the Internet of Things (IoT) reputation systems, especially their lack of scalability. They introduce a distributed ledger combining Tangle and blockchain as a reputation framework. Combining Tangle with blockchain is destined to provide maintainability of the former and scalability of the latter. Consequently, the proposed ledger could handle a more significant number of IoT devices and transactions.

Blockchain has had a wide range of applications due to its outstanding features such as security and reliability, especially in distributed settings [26,27,28,29]. Among other applications is fog computing, where blockchain may achieve secure decentralized reputation systems and identity management [30].

Similarly, the authors in [21] proposed a decentralized reputation management system for the Internet of Things (IoT) that takes into account geospatial information. The proposed system recognizes that the trustworthiness of a device can be affected by various factors, including its geographical location. The system utilizes a cloud–fog–edge architecture, in which the fog layer employs blockchain technology to create a decentralized network among fog nodes, allowing for transparent and decentralized management. The location-based system component stores geographical information in smart contracts, enabling reputation values to vary based on the device’s location.

In the field of VANETs, decentralized reputation systems were proposed in works such as [31], where the authors utilized a Bayesian filter to enable nodes to detect malicious vehicles based on their trust scores. Additionally, the authors in [32] proposed a two-layered blockchain-based reputation system comprising a local, one-day message blockchain and a global vehicle reputation blockchain. The local blockchain efficiently manages local traffic information, reducing the memory overhead for vehicles, while the global one maintains reputation scores.

Based on the literature review and the classification of related works according to four criteria, namely: Full Decentralization, General-Purpose, Global Reputation, and Privacy (as summarized in

Table 1. A Comparative study of privacy-preserving decentralized reputation systems.

Paper	Reference	Year	Fully Decentralized	Global Reputation	General-Purpose	Privacy
Pavlov, et al.	[6]	2004	✓	x	✓	✓
Hasan, et al.	[9]	2013	✓	x	✓	✓
Clark, et al.	[10]	2017	✓	x	✓	✓
Debe, et al.	[19]	2019	x	✓	x	x
Liu, et al.	[20]	2019	x	✓	x	✓
Azad, et al.	[23]	2018	x	✓	x	✓
Bag, et al.	[24]	2018	x	✓	x	✓
Azad, et al.	[15]	2020	x	✓	x	✓
Li, et al.	[17]	2021	x	✓	x	✓
Najafi, et al.	[31]	2021	x	✓	✓	x
Lee, et al.	[32]	2022	x	✓	x	✓
Weerapanpisit, et al.	[21]	2022	x	✓	x	x
Our system.			✓	✓	✓	✓

), it is clear that a portion of the related works are fully decentralized reputation systems and general-purpose, but do not maintain global reputation scores and rely on locally stored information. As a result, their produced reputation information is partial and inconsistent across the network, as it is limited to users’ direct experience and recommendations from neighbors and acquaintances. On the other hand, another portion of related works is proposed for specific settings and achieves global reputation and some form of decentralization, but they are not general-purpose systems. The current work objective is to fill this gap by proposing a global reputation system that is both general-purpose and fully decentralized.

2.2. Blockchain

Typically, a blockchain can be seen as a distributed public database from which every user can read, but not any user can write. Rather, users need to reach a consensus over the network before the writing is accepted [33]. All actions that modify this database are recorded and broadcast to all users in blocks. Once a block is received and accepted by network users, it becomes immutable after a few following blocks. Furthermore, blockchain is reputed for recording transactions efficiently in a verifiable and permanent way. Owing to this fact, it is considered an append-only database.

From another point of view, blockchain can be regarded as a data structure composed of an ordered list of blocks as depicted in Figure 1. The result of all actions in all blocks at a given moment constitutes the state of the blockchain.

Let ${\left({\mathrm{B}}_i\right)}_{(0\le i\le l)}$ be a blockchain, where the first block ${\mathrm{B}}_0$ is the genesis block, while ${\mathrm{B}}_l$ is the last validated block. Each block ${\mathrm{B}}_i$ contains a cryptographic hash of its precedent block ${\mathrm{B}}_{i-1}$, which makes the blockchain resistant to modification by design. Once recorded, the data in any given block cannot be modified without altering all the previous blocks, which requires the consensus of the network majority. A blockchain is typically managed by a P2P network adhering to a communication protocol.

The $i^{\mathrm{th}}$ block ${\mathrm{B}}_i$ is composed of a block header ${\mathrm{H}}_i$ and a series of transactions ${\mathrm{T}}_i$. The block header ${\mathrm{H}}_i$ includes a collection of relevant data fields, whereas the transactions series ${\mathrm{T}}_i=(T{x}_i^{\left(1\right)},\dots ,T{x}_i^{\left(n\right)})$ is the list of transactions comprised in this block. Specifically, transactions are organized in each block as a Merkle tree data structure. In addition, the Merkle tree has its root hash called TransactionsRoot in the block header.

For simplicity, a block can be formulated as:

$${\mathrm{B}}_i=\{{\mathrm{H}}_i,(T{x}_i^{\left(1\right)},\dots ,T{x}_i^{\left(n\right)})\}$$

(1)

where ${\mathrm{H}}_i$ includes several data fields, among them [33,34]:

• PreviousBlockHash: The hash of the previous block’s header.
• StateRoot: The hash of the root node of the state tree.
• TransactionsRoot: The hash of the root node of the transactions’ Merkle tree.

A transaction $Tx$ is a single instruction constructed by a party and signed cryptographically. It is traditionally used to transfer a sum of coins (virtual money). In our context, it is also used to submit parties’ feedback to the blockchain and to join source parties’ lists (c.f. Section 3). Mainly, it contains some common data fields, namely:

• Nonce: A scalar value equal to the number of transactions issued by the sender;
• Recipient: The address of the recipient.
• Type: The transaction type: $Transfer$ for coins transfer; $Rate$ for rating peers; and $Join$ for the joining recipient’s source parties list.
• Data: A value that depends on the transaction type.
• Signature: The transaction signature, also used to recover the sender’s address.

$$Tx=<\mathrm{Nonce};\mathrm{Recipient};\mathrm{Type};\mathrm{Data};\mathrm{Signature}>$$

(2)

2.2.1. State

The state, as described in [34,35], is a mapping between parties’ addresses and their state accounts. It is implemented and maintained in the form of a modified Merkle tree. It is a simple database linked to blocks, but not stored on the blockchain. The state database can be considered a condensed version of the blockchain, as it only contains the essential information for regular users, specifically accounts and balances. It is the only data structure, in addition to the blocks’ headers, required for non-miner users to participate in the network. In the context of this work, reputation scores are also stored in the state. Ethereum is an example of a blockchain that implements a state database, unlike Bitcoin, which does not have an equivalent structure, as stated in [36].

We denote the state database as $\sigma$ and use a party’s address a to reference its account denoted by ${\sigma }^{\left(a\right)}$. In the context of this research, the account state includes the following data fields:

• Nonce: The number of transactions sent from this address, denoted ${\sigma }_n^{\left(a\right)}$.
• Balance: The number of coins owned by this address, denoted ${\sigma }_b^{\left(a\right)}$.
• Reputation: The reputation score, denoted ${\sigma }_r^{\left(a\right)}$.
• Weight: The number of feedback received so far, denoted ${\sigma }_w^{\left(a\right)}$.
• Source Parties List: The list of source parties’ addresses, denoted ${\sigma }_l^{\left(a\right)}\left[\right]$.

Figure 2 shows all the blockchain components and how they are linked.

2.2.2. Consensus

The creation of blocks is controlled by a mechanism that varies between different blockchain algorithms. The first mechanism used to reach consensus [37] on newly created blocks was the Proof-of-Work (PoW). The concept started with the blockchain/currency Bitcoin [12] and was followed by several alternative coins launched using similar ideas.

The mechanism of PoW requires block creators, called miners, to prove that they performed a certain amount of work to write to the blockchain. Usually called mining, this task consists of finding a partial collision using hash functions, which is a power-consuming process often requiring dedicated hardware [38].

With the advent of PPCoin [39] developed further by BlackCoin [40], NXT [41], and NeuCoin [42], a new family of blockchain-based systems was born, replacing PoW with the concept of Proof-of-Stake (PoS).

With the PoS, every participant randomly gains the right to write to the blockchain with a probability proportional to their stake, i.e., the number of coins they staked. Therefore, the additional computing power used in PoW becomes useless. Accordingly, it is less costly to run the PoS and particularly much faster to create new blocks under it. After some of its inherent issues were tackled [39,40,42], it is perfectly reasonable today to maintain a distributed consensus using the PoS. In this regard, we consider the PoS more appropriate in our context than the PoW.

During the block creation process, miners, also known as validators, perform various tasks. Among them, they record new transactions and validate new blocks. Usually, a new block is validated on regular periods. When transactions become part of an accepted block, they are considered confirmed. Consequently, all the concerned users’ state accounts are updated to reflect the changes made by the transactions in that block.

Whether the consensus mechanism uses mining in the case of PoW or validation in the case of PoS, block creation has a cost for miners/validators. This task is attractive for them only because they are rewarded by earning transaction fees. In this regard, it is crucial to highlight that the role of a reputation system is to support the network’s operation by establishing trust between the users and encouraging participation and good behavior. Thus, it is counterproductive to impose fees on users that provide their feedback, as it is already challenging to persuade them to do so without fees. Additionally, assuming some activity and transactions in the network other than rating and reputation—otherwise, the very existence of the network would be pointless—it is those types of transactions that have to pay for the block creation process. Because reputation functionalities are essential functionalities just like security, we cannot compare them with financial transactions, for example.

2.3. Secure Multiparty Computation

Using SMC, a set of parties can collaboratively compute a function over their private inputs without disclosing them. With n parties ${\left(P_i\right)}_{1\le i\le n}$, each one holding a secret input $x_i$, and f an agreed-upon function that accepts n inputs: A protocol ${\Pi }$ is a SMC one if it allows ${\left(P_i\right)}_{1\le i\le n}$ to compute $y=f(x_1,...,x_n)$ while meeting the following criteria:

• Correctness: The protocol ${\Pi }$ correctly computes the value of y;
• Privacy: $\forall i/1\le i\le n$ The $n-1$ parties ${\left(P_j\right)}_{1\le j\ne i\le n}$ cannot learn any information about $x_i$, but y from the protocol.

In order to calculate a function f, which is typically represented as a Boolean or arithmetic circuit, one must evaluate the equivalent circuit gate by gate. There are currently two paradigms for Secure Multi-Party Computation (SMC) implementation: secret sharing [43,44,45,46], and garbled circuits [47,48,49]. Each paradigm has its own advantages and development trajectory. In our system, we use secret sharing, as it is more adapted to arithmetic circuits.

In the following paragraphs, we will introduce the variant of SMC used in our system, which is adapted from [50] for arithmetic circuits. This protocol is considered in the semi-honest adversarial model. However, we do not use the entire protocol. Instead, we only include the elements of the protocol that are pertinent to our setting and particularly appropriate for the reputation-related functions we are focusing on (c.f. Section 2.4.1).

Reputation functions typically determine reputation scores from ratings provided by users. They usually take the form of a sum, an average, or a weighted average, which we can represent as linear functions of the kind $f(x_1,\dots ,x_n)=a_1{x}_1+\dots +a_n{x}_n$ where ${\left\{x_i\right\}}_{1\le i\le n}$ are private values and ${\left\{a_i\right\}}_{1\le i\le n}$ are public. Remarkably, these functions employ only addition and multiplication by public values.

Let us assume that the desired function f is given as an arithmetic circuit composed of only addition and multiplication by public values.

In accordance with this protocol, secret-sharing a value $x\in {\mathbb{Z}}_p$ entails sampling $n-1$ uniform random shares ${\left\{x^{\left(i\right)}\right\}}_{1\le i\le n-1}\subset {\mathbb{Z}}_p$ and taking the $n^{th}$ share as $x^{\left(n\right)}=x-{\sum }_{i=1}^n{x}^{\left(i\right)}modp$. The outcome is an additive secret sharing of x, which is represented by $\left[x\right]=({\left[x\right]}_1,\cdots ,{\left[x\right]}_n)$, where ${\left[x\right]}_i=x^{\left(i\right)}$ for $1\le i\le n$. Practically speaking, a party can generate $\left[x\right]$ as indicated and send a share ${\left[x\right]}_i$ to each party if it wishes to share its secret x with $n-1$ parties. The value of x will remain private as long as the party keeps the $n^{\mathrm{th}}$ share secret, and adding the n shares is sufficient to recover x.

The SMC protocol for n parties ${\left\{P_i\right\}}_{1\le i\le n}$ computing $y=f(x_1,\dots ,x_n)$ from their respective private inputs, works as follows:

1.

Input: Every party $P_i$ secret-shares its private input $x_i$ by generating $\left[x_i\right]$ and sending ${\{{\left[x_i\right]}_j\}}_{1\le j\ne i\le n}$, respectively, to ${\left\{P_j\right\}}_{1\le j\ne i\le n}$ while keeping ${\left[x_i\right]}_i$ secret.

2.

Computation: Each party $P_i$ calculates f over the shares they received ${\left[y\right]}_i=f({\left[x_1\right]}_i,\dots ,{\left[x_n\right]}_i)$ by evaluating operations in the order and precedence. The operations are realized as follows:

(a)

Addition: For example, $y=x_1+x_2$ is realized by each party $P_i$ computing ${\left[y\right]}_i={\left[x_1\right]}_i+{\left[x_2\right]}_i$.

(b)

Multiplication by a public value: For example, $y=a\times x$ for a public and x private is computed by each party $P_i$ evaluating ${\left[y\right]}_i=a{\left[x\right]}_i$.

3.

Output: A party $P_i$ can learn the result of computation y by each party $P_j$ sending ${\left[y\right]}_j$ to $P_i$ and party $P_i$ reconstructing $y={\left[y\right]}_1+\cdots +{\left[y\right]}_n$.

It is simple to check that the protocol computes f precisely. The protocol is secure against any passive adversary controlling up to $n-1$ parties. Indeed, the adversary cannot unveil the value of x unless he knows all shares in the representation $\left[x\right]$.

From the previously mentioned operations, the SMC protocol can handle any linear function $f(x_1,\dots ,x_n)=a_1{x}_1+\dots +a_n{x}_n$, which is amply sufficient for reputation functions.

The original protocol is broader than described above. It can handle the multiplication of two private values and, by extension, any arithmetic circuit since addition and multiplication form a complete basis for arithmetic circuits.

2.4. Problem Setting & Definitions

We model our environment as a multi-agent environment, where each agent represents a user or any devices executing the necessary computation and communication on behalf of them. We often use the word “party” instead of “agent” without changing the meaning. Let $\mathbb{P}$ be the set of all parties existing in the environment and $N=\left|\mathbb{P}\right|$. We associate with each party $P_i\in \mathbb{P}$ an account that is controlled by a pair of private/public keys, denoted ($p_r^{\left(i\right)}$, $p_u^{\left(i\right)}$). A party and its associated account are usually identified by a short address $a_i$ derived from its public key $p_u^{\left(i\right)}$ by taking the right-most 160-bits of its 256-bit SHA-3 hash [34]:

$$a_i=\mathrm{Address}(p_u^{(a_i)})={\mathrm{Bits}}_{96..255}(\mathrm{SHA}{3}_{256}(p_u^{(a_i)}))$$

(3)

2.4.1. Trust and Reputation

Let us introduce the following notations:

• $\mathbb{T}\subseteq \mathbb{P}\times \mathbb{P}$ denote the set of all trust relationships between parties in $\mathbb{P}$, where $(a,t)\in \mathbb{T}$ (or $a\mathbb{T}t$) implies that the party a has a trust relationship towards a target party t. Mainly, $\mathbb{T}$ is a binary relation that is not necessarily symmetric, as trust is a directional relation.
• $\mathbb{A}$ denotes the set of all actions, e.g., “upload authentic content”, or “report an event”.
• $Exec$ refers to the function

  $$Exec:\mathbb{P}\times \mathbb{A}\to \{true,false\}$$

  (4)

  such that $Exec\left(t,\psi \right)$ outputs $true$ if party t executes the action $\psi$ anticipated by party a, or outputs $false$ if t does not perform the anticipated action. Let the subjective probability $\mathrm{Pr}{[Exec(t,\psi )=true]}_a$ denote party a’s belief that party t will accomplish the action.

Without a loss of generality and for practicality’s sake, we can assign to the subjective belief mentioned above an equivalent integer value in the interval $[0,M]$ where M is a fixed positive integer. The integer value is obtained by normalizing the probability $\mathrm{Pr}{[Exec(t,\psi )=true]}_a$ to the scale $[0,M]$, which is done by multiplying by M, adding $1/2$ and taking the floor. The result is an integer in the range $[0,M]$.

Definition 1

(Trust). Let $\mathbb{P}$ be the set of all parties, $\mathbb{A}$ be the set of all actions and $a,t\in \mathbb{P}$. The trust of party a in party t expressed as an integer and reported to the scale $[0,M]$ is given as:

$${\tau }_t^{\left(a\right)}=\lfloor \mathrm{Pr}{[Exec(t,\psi )=true]}_a\times M+1/2\rfloor$$

(5)

where $\psi \in \mathbb{A}$ and $M\in {\mathbb{Z}}_p$ with p a prime number.

A party a is said to be a source party of a target party t in the context of an action $\psi$ if a has trust in t in the context $\psi$. The set of all source parties of a party t in context $\psi$ is denoted ${\mathcal{S}}_{t,\psi }$. When the context (action) is clear, the notation ${\mathcal{S}}_t$ is used. We also refer to a’s trust in party t as a’s feedback on t or the rating.

Definition 2

(Reputation). A reputation function is any chosen function $Rep$ such that $Rep:{[0,M]}^n\to \mathbb{R}$ ($M\in {\mathbb{Z}}_p$). Let ${\mathcal{S}}_t=\{a_1...a_n\}$ be the set of source parties of party t in the context ψ. If $Rep$ is the adopted reputation function, then the reputation of party t in the context ψ is defined as:

$${\rho }_{t,\psi }=Rep({\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)})$$

(6)

where ${\tau }_t^{\left(a_i\right)}$ is the trust of party $a_i$ in party t for $1\le i\le n$. ${\rho }_{t,\psi }$ is also denoted ${\rho }_t$ when the context is clear.

Reputation, in general, is the outcome of evaluations from various sources. It is often represented as a function of these evaluations, such as the sum or average [2]. There are a variety of methods for aggregating reputation from ratings, including counting [51], probabilistic [52], discrete [53], flow [54], and fuzzy approaches [55]. However, a comprehensive examination of these methods is beyond the scope of this study. In this work, we adopt the counting approach for reputation, which is implemented as the average of feedback values due to its simplicity and ease of comprehension by human users. Other linear functions, such as the weighted average, could also be utilized without any alteration to the proposed system. The reputation is recorded on the blockchain as a pair $({\sigma }_r^{\left(t\right)},{\sigma }_w^{\left(t\right)})$ (refer to Section 2.2.1), where ${\sigma }_r^{\left(t\right)}={\rho }_t$ represents the reputation score and ${\sigma }_w^{\left(t\right)}=n$ represents the number of ratings, also known as weight. This way, the weight of this measure is preserved.

The weight of a reputation score is an essential factor in determining its overall value, as it reflects the number of ratings or evaluations that have been used to calculate the reputation score. The higher the weight, the more evaluations have been taken into account, making the reputation score more reliable and representative of the overall perception of an entity. To ensure that the weight of the reputation score is preserved, we record it alongside the reputation score on the blockchain. For further discussions on reputation aggregation, one can refer to the works of [1,2].

$$\begin{array}{cc}\hfill \left({\sigma }_r^{\left(t\right)},{\sigma }_w^{\left(t\right)}\right)& =\left({\rho }_t,n\right)\hfill \\ \hfill & =\left(Rep({\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)}),n\right)\hfill \\ \hfill & {\displaystyle =\left(\frac{{\sum }_{i=1}^n{\tau }_t^{\left(a_i\right)}}{n},n\right)}\hfill \end{array}$$

(7)

2.4.2. Security Definition and Adversary Model

In the following, we present the adversary model for our system, some important assumptions, and system requirements.

• Adversary Model: In this paper, we consider the model of multiparty computation in the presence of static semi-honest adversaries. Parties in such a model are supposed to follow the protocol, but may try to learn more information than allowed during the execution of the protocol using intermediate information and their internal states. We call any coalition of dishonest parties adversaries.
• Random Number Generator & Hash Function: All parties in the network are granted access to a random number generator, denoted RandGen(), to achieve privacy for our system and use the Keccak 256 algorithm [56] as the default hash function denoted $h\left(\right)$. Keccak is a robust hashing algorithm at the core of SHA-3 and is also part of Solidity [57] and Ethereum.
• Authentication: Our system uses public-key cryptography. It authenticates each user through digital signatures enabling them to exchange messages and perform transactions. Every user obtains a public and a private key forming his digital identity. They use the private key to sign messages and transactions linking them to their identity, while other users can verify the signer’s identity using the public key visible to all network participants. A valid signature gives a recipient confidence that the message was created by a known sender (authenticity) and was not altered in transit (integrity). Regularly, a signature scheme is a tuple of algorithms (Gen(), Sign(), Verify()) where Gen() generates a private key $p_r$ and a corresponding public key $p_u$; Sign() returns a tag t on the inputs of the private key $p_r$, and a message m; and Verify() outputs accepted or rejected on the inputs of a public key $p_u$, a message m, and a tag t. In our context, the system uses the elliptic curve digital signature algorithm (ECDSA) [58] specifically, the recoverable version of it [34] consisting of three functions that are PUBKEY, SIGN and RECOVER, defined as follows:

• $PUBKEY\left(p_r\right)=p_u$ returns $p_u$, a 512-bit public key on the input of a randomly generated 256-bit private key.
• $SIGN(m,p_r)=(v,r,s)$ returns a tag $(v,r,s)$ as a signature on the inputs of a public key $p_u$ and a message m.
• $RECOVER(m,v,r,s)=p_u$ returns the public key $p_u$ of the signer if $(v,r,s)$ is a valid signature or nothing otherwise.

• Recoverable ECDSA is a variant of the ECDSA that allows for the recovery of the public key used to generate a signature from the signature itself. This is useful in certain situations, especially when multiple parties are signing a message, as it allows for a more efficient verification process without the need to store multiple copies of each party’s public key.
• Encryption: On the other hand, for privacy purposes, the Elliptic Curve Integrated Encryption Scheme (ECIES) [59] is used to encrypt messages between parties.
• Communication channels: We assume that point-to-point channels exist between every pair of parties and postulate that they are reliable and guarantee the authenticity of the data sent through them. In addition, we assume they are private, so the adversary cannot obtain messages sent between honest parties. Point-to-point private channels are emulated in our context through signature and encryption.
• Privacy in the Semi-Honest Model: Recall that in the semi-honest model, it is assumed that the parties involved in SMC will follow the protocol as prescribed, but they may attempt to gain additional information beyond what they are supposed to learn during the computation. Privacy in this model refers to the ability of the parties to keep their inputs confidential from one another during the computation, while still permitting the correct output to be computed.
• A SMC protocol is considered to privately compute a function f if the information obtained by any subset of semi-honest parties during the execution of the protocol is the same as what they could learn by just looking at their inputs and the outputs. In other words, the protocol ensures that the parties do not learn any additional information about the inputs of other parties beyond what can be inferred from their own inputs and the outputs.
• In formal terms [60]: Let $\{a_1,\dots ,a_k\}$ be the parties participating in a SMC with the inputs $\{x_1,\dots ,x_k\}$, respectively, $I=\{i_1,\dots i_t\}\subseteq \{1,\dots ,k\}$ a subset of semi-honest parties representing the adversary, and ${\mathbf{view}}_I^{{\Pi }}$ denotes their view on the protocol ${\Pi }$, which is the set of all the information obtained by the adversary I from the protocol during its execution. There exists a polynomial-time algorithm $\mathcal{S}$ known as a simulator that can produce the same view from just the inputs of I $x_{i_1},\dots ,x_{i_t}$ and the output $f(x_1,\dots ,x_k)$. In computational security, this is expressed and equivalent to the indistinguishability of two distributions ${\left\{\mathcal{S}(I,x_{i_1},\dots ,x_{i_t},f\left(\overline{x}\right))\right\}}_{\overline{x}\in {\left({\{0,1\}}^{*}\right)}^k}$ and ${\left\{{\mathbf{view}}_I^{{\Pi }}\left(\overline{x}\right)\right\}}_{\overline{x}\in {\left({\{0,1\}}^{*}\right)}^k}$.
• O. Goldreich [60] specifies the security definition of privacy for multiparty computation in the semi-honest model as follows:

Definition 3.

Let $k\in \mathbb{N}$ and $\overline{x}\in {\left({\{0,1\}}^{*}\right)}^k$ where $\overline{x}=(x_1,\dots ,x_k)$. Let $f:{\left({\{0,1\}}^{*}\right)}^k\to {\{0,1\}}^{*}$ a deterministic functionality. We say that a protocol Π privately computes f if there is a probabilistic polynomial time algorithm denoted $\mathcal{S}$ (a simulator) such that for every $I=\{i_1,\dots i_t\}\subseteq \{1,\dots ,k\}$, it holds that:

1.

${\mathit{output}}^{{\Pi }}\left(\overline{x}\right)=f\left(\overline{x}\right)$ (Correctness)

2.

${\left\{\mathcal{S}(I,x_{i_1},\dots ,x_{i_t},f\left(\overline{x}\right))\right\}}_{\overline{x}\in {\left({\{0,1\}}^{*}\right)}^k}\stackrel{c}{\equiv }{\left\{{\mathbf{view}}_I^{{\Pi }}\left(\overline{x}\right)\right\}}_{\overline{x}\in {\left({\{0,1\}}^{*}\right)}^k}$ (Privacy)

where “Correctness” means that the protocol computes and outputs the desired function $f\left(\overline{x}\right)$, namely ${\mathit{output}}^{{\Pi }}\left(\overline{x}\right)=f\left(\overline{x}\right)$.

• Accessibility: Accessibility refers to the ability of a reputation system to facilitate the utilization and access of reputation information for all users. In decentralized reputation systems, this entails ensuring that all individuals, regardless of their location and the data they possess, can utilize and benefit from others’ reputation scores.

Definition 4.

We say that a reputation system Π achieves Accessibility if $\forall a,t\in \mathbb{P}$ a can query for the reputation score of t at any time and always obtains a copy of ${\rho }_t={\sigma }_r^{\left(t\right)}$ according to its request time.

• Consistency: Consistency refers to the uniformity or unchanging nature of the reputation system across the network. In decentralized reputation systems, consistency is crucial as it ensures that the output reputation scores are comparable and reliable across the network when requested simultaneously.

Definition 5.

We say that a reputation system Π is Consistent if $\forall a,b,t\in \mathbb{P}$, if a and b query for the reputation score of t at the same time and obtain ${\rho }_t$ and ${\rho }_t^{\prime }$, respectively, then ${\rho }_t={\rho }_t^{\prime }$.

• Conservation: Conservation in the context of decentralized reputation systems refers to the safeguarding and preservation of reputation and feedback information. In more straightforward terms, it entails ensuring that valuable information is not lost, even when the provider of feedback leaves the network.

Definition 6.

We say that a reputation system Π conserves the reputation information if $\forall t\in \mathbb{P}$ such that a party a has rated t before, then ${\rho }_t$ remains a function of its rating even if a leaves the network.

• Verifiability: In decentralized reputation systems, verifiability refers to the capability for reputation scores and rating transactions to be independently examined and confirmed by any user, rather than being accepted solely based on trust or authority. This process involves verifying the qualifications of raters, signatures, nonces, and the calculation of reputation scores.

Definition 7.

We say that a reputation system Π achieves verifiability if $\forall t\in \mathbb{P}$ such that the system has received for t so far n feedback ${\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)}$ from parties $a_1...a_n$, respectively: then any party can check that the reputation score of t at this time is ${\sigma }_r^{\left(t\right)}=Rep({\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)})$ and that the number of ratings is ${\sigma }_w^{\left(t\right)}=n$.

2.4.3. Problem Definition

Let $S_t=\{a_1,\dots ,a_n\}$ be the set of source parties of a target party t in the context of a given action $\psi$. We assume that $\psi$ is known and unique for simplicity. We examine the situation where the set of t’s source parties $S_t$ execute a reputation system ${\Pi }$, which takes their private feedback $\overline{{\tau }_t}=({\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)})$, securely computes the functionality ${\displaystyle {\rho }_t=Rep({\tau }_t^{\left(a_1\right)},\dots ,{\tau }_t^{\left(a_n\right)})=\frac{{\sum }_{i=1}^n{\tau }_t^{\left(a_i\right)}}{n}}$, and outputs ${\rho }_t$ the reputation score of target party t. The reputation system ${\Pi }$ is required to be decentralized and secure under the semi-honest model.

3. The Reputation System

3.1. System Overview

The proposed system is structured into three distinct phases, as described below. Each one has its specific objective and task. A graphical overview of the system is presented in Figure 3 in addition to a summary of the system parameter choices in

Table 2. System parameters.

Parameters	Values
Blockchain	Ethereum or any Blockchain with a State
Consensus	Proof of Stake
Transactions	JOIN & RATE
SMC security	Semi-honest
Reputation function	The average
Subgroup cardinality	k (fixed)
Thresholds	$T_r$ and $T_w$ fixed for the reputation score and the weight, respectively.

:

• In the first phase, each witness joins the list of source parties by submitting a JOIN transaction. After successful validation, the witness is assigned to a subgroup U consisting of k parties. The purpose of this phase is to ensure that witnesses are legitimate and have the necessary credentials to participate in the rating process.
• The second phase is where most of the actual reputation calculation takes place. Each subgroup runs the Secure Multi-Party Computation protocol, which allows parties to jointly compute a reputation rating without revealing their individual inputs. Once the joint rating is calculated, it is submitted to the blockchain via a RATE transaction. This phase aims to ensure that the reputation calculation is secure, accurate, and tamper-proof.
• In the final phase, the miners execute the RATE transaction and calculate the final reputation score based on the received ratings. The reputation value is then updated on the blockchain, making it publicly available for all participants. This phase aims to ensure that the reputation value is accurate, transparent, and accessible to all parties on the network.

3.2. System Specification

The system presumes that a particular action has been executed by the targeted party and that the participating parties have based their evaluations on the quality of that action. Furthermore, it is assumed that all participating parties possess a piece of data, referred to as $Trace$, as evidence of the interaction that has transpired. Based on this evidence, they can be added to the list of source parties and compute reputation collectively. Subsequently, the resulting score is submitted to the blockchain for integration.

If a party is new to the network or possesses a poor reputation, it is unable to be added to the list of source parties and, as a result, is unable to evaluate other parties. However, it can enhance its reputation by exhibiting positive behavior and receiving positive feedback from its peers. Nevertheless, only parties with reputation scores higher than a predefined threshold $T_r$ and the number of received evaluations exceeding $T_w$ are permitted to evaluate others (see Section 3.3).

Let $S_t=\{a_1,\dots ,a_n\}$ be the set of source parties of a party t. We recall that, if $a_i\in S_t$, then $a_i$ represents the source party address and ${\sigma }^{\left(a_i\right)}$ its account state. If the source parties want to share their feedback and n is large, they are divided into subgroups that do not exceed k parties, and each party is assigned to a subgroup. k is a system-wide fixed parameter chosen to be as small as possible (see Section 3.4).

1.

In the first phase specified in Algorithm 1, the source parties join the list of source parties and are assigned to a subgroup U of k parties from the list.

2.

Each subgroup runs the second phase specified in Algorithm 2 independently and submits its result as a transaction to the blockchain. Any source party can initiate the second phase by requesting parties in its subgroup U for SMC computation. We refer to that party by $a_1$ for simplicity and to the set of selected parties by $U=\{a_1,\dots ,a_k\}$.

3.

In the third phase specified in Algorithm 3, the miner that gained the right to form the new block executes the transactions and updates the state.

Algorithm 1 Phase 1: Joining the list of source parties and forming subgroups.

for all$a_i\in S_t$do    if $a_i$ issues a Join transaction $Tx=<Nonc{e}_i,t,Join,Trac{e}_i,Signatur{e}_i>$ then          The miner:          if $RECOVER\left(Signatur{e}_i\right)\ne ⌀$ then            $p_u^{\left(a_i\right)}\leftarrow RECOVER\left(Signatur{e}_i\right)$.            $a_i\leftarrow \mathrm{Address}\left(p_u^{\left(a_i\right)}\right)$            if:   The $Trac{e}_i$ is valid and not used before in previous JOIN transactions;                   and                   $a_i$’s reputation score is ${\sigma }_r^{\left(a_i\right)}>T_r$ and its weight ${\sigma }_w^{\left(a_i\right)}>T_w$;                   and                   $Nonc{e}_i={\sigma }_n^{\left(a_i\right)}+1$            then   The miner appends the address of party $a_i$ to the list of t’s source parties ${\sigma }_l^{\left(t\right)}\left[\right]$ and assigns $a_i$ to a subgroup U of source parties according to its order in the queue.          end if    end if end for

Algorithm 2 Phase 2: Secure multiparty computation.

Require:U a subgroup of k source parties  $a_1$ sends requests to participants in U to start SMC computation.  Prepare Shares:  for all $a_i\in U$do      $a_i$ prepares k shares of its private feedback ${\tau }_t^{\left(a_i\right)}$:      The shares denoted ${[{\tau }_t^{\left(a_i\right)}]}_1,\cdots ,{[{\tau }_t^{\left(a_i\right)}]}_k$ are prepared by generating the $k-1$ random      integers ${\{{[{\tau }_t^{\left(a_i\right)}]}_j\}}_{1\le j\le k}^{j\ne i}$ uniformly distributed over the large interval $[0,p]$      and selecting the last share ${[{\tau }_t^{\left(a_i\right)}]}_i$ such that ${\sum }_{j=1}^k{[{\tau }_t^{\left(a_i\right)}]}_j={\tau }_t^{\left(a_i\right)}modp$ $${\displaystyle {[{\tau }_t^{\left(a_i\right)}]}_i={\tau }_t^{\left(a_i\right)}-\sum _{j=1j\ne i}^k{[{\tau }_t^{\left(a_i\right)}]}_{j}modp}$$  end for  Send Shares: Every party $a_i$ sends the share ${[{\tau }_t^{\left(a_i\right)}]}_j$ signed and encrypted to party $a_j$,  where $j\in \{1\dots k\}\backslash \left\{i\right\}.$  Receive Shares: Each party $a_i$ then receives and decrypts shares from the parties in  $U\backslash \left\{i\right\}$, and verify their signatures.  Compute Sums: Every party $a_i$ computes ${\delta }_i$ the sum of all shares received plus its own  private share ${[{\tau }_t^{\left(a_i\right)}]}_i$:    ${\delta }_i={\displaystyle \sum _{j=1}^k}{[{\tau }_t^{\left(a_j\right)}]}_i$  Signature & Nonce: Each party $a_i$ signs ${\delta }_i$: $Si{g}_i=SIGN(h\left({\delta }_i\right),p_r^{\left(a_i\right)})$, and sets the nonce  to $Nonc{e}_i={\sigma }_n^{\left(a_i\right)}+1$  Send Signed Sums: Each party $a_i$ sends the tuple $(Nonc{e}_i,{\delta }_i,Si{g}_i)$ to $a_1$.  Submit Transaction: $a_1$ submit a transaction $T{x}_U$ to be included in the next block:  $T{x}_U=\{<Nonc{e}_1,\dots ,Nonc{e}_k>;t;Rate;<{\delta }_1,\dots ,{\delta }_k>;<Si{g}_1,\dots ,Si{g}_k>\}$

Algorithm 3 Phase 3: Reputation aggregation on-chain (performed by miners).

Require:$T{x}_U=\{<Nonc{e}_1,\dots ,Nonc{e}_k>;t;Rate;<{\delta }_1,\dots ,{\delta }_k>;<Si{g}_1,\dots ,Si{g}_k>\}$  Verify the transaction:  Check the signatures $Si{g}_1,\dots ,Si{g}_k$ are valid.  if $RECOVER\left(Si{g}_i\right)\ne ⌀$ for $1\le i\le k$ then         Recover signers’ addresses $a_1,\cdots ,a_k$ from the signatures $Si{g}_1,\dots ,Si{g}_k$.         $a_i\leftarrow \mathrm{Address}\left(RECOVER\left(Si{g}_i\right)\right)$ for $1\le i\le k$         Verify the signers membership $a_i\in {\sigma }_l^{\left(t\right)}\left[\right]$ for $1\le i\le k$.         Check that the nonces in $T{x}_U$ verify $Nonc{e}_i={\sigma }_n^{\left(a_i\right)}+1$ for each party $a_i$.         Record the transaction in the current mined block.         Compute reputation from the received sums ${\delta }_j$ for $1\le i\le k$:       ${\rho }_t=({\displaystyle \sum _{j=1}^k}{\delta }_j)/k.$         Update reputation scores and nonces in the account state of t:               ${\sigma }_n^{\left(a_i\right)}\leftarrow {\sigma }_n^{\left(a_i\right)}+1$ for all $a_i\in U$               ${\sigma }_r^{\left(t\right)}\leftarrow ({\sigma }_r^{\left(t\right)}\times {\sigma }_w^{\left(t\right)}+{\rho }_t\times k)/({\sigma }_w^{\left(t\right)}+k)$               ${\sigma }_w^{\left(t\right)}\leftarrow {\sigma }_w^{\left(t\right)}+k$         Remove the participating parties from the source parties list ${\sigma }_l^{\left(t\right)}\left[\right]$  end if

3.3. Reputation Threshold

The system uses thresholds to ensure a minimum level of trustworthiness within the network. Newcomers or parties with low reputations are not allowed to participate in witness groups and cannot rate other parties. However, they can improve their reputation score by exhibiting good behavior and receiving positive feedback from their peers. Both the reputation score and the number of received ratings, called reputation weight, are taken into account, with a threshold set for each. Therefore, the thresholds $T_r$ and $T_w$ represent the minimum reputation score and weight required for parties to participate in the network.

The threshold on reputation weight is included in the system to ensure that feedback from parties is coming from a diverse group of participants. By requiring a minimum number of ratings before a party’s feedback is considered, the system aims to prevent a single or small group of parties from having an outsized influence on the reputation of others.

However, the threshold on reputation weight could also make it difficult for new parties to establish a reputation and participate in the network, limiting the diversity of the network, hence the need for a trade-off between security and decentralization. The threshold can be adjusted depending on the desired balance between security and decentralization for the network.

3.4. Which Value k for the System

Conducting a secure multiparty computation with all n source parties participating simultaneously, especially in dynamic networks where parties may enter and exit the network, is a challenging task. Furthermore, the task requires $O\left(n^2\right)$ messages, which can be significantly reduced by dividing the set of source parties into subgroups of a fixed number k. As per Theorem A1, privacy is ensured if each subgroup contains at least two honest parties. The probability of having at least two honest parties in each subgroup, when parties are selected uniformly at random, is equal to $1-[(n-b)\left(\genfrac{}{}{0pt}{}{b}{k-1}\right)+\left(\genfrac{}{}{0pt}{}{b}{k}\right)]/\left(\genfrac{}{}{0pt}{}{n}{k}\right)$, where k is the number of participating parties, n is the total number of source parties, and b is the total number of corrupt parties. We denote this probability as $Pr\left(k\right)$ in relation to the value of k.

$$Pr\left(k\right)=1-\frac{(n-b)\left(\genfrac{}{}{0pt}{}{b}{k-1}\right)+\left(\genfrac{}{}{0pt}{}{b}{k}\right)}{\left(\genfrac{}{}{0pt}{}{n}{k}\right)}for2\le k\le nandb\le n$$

(8)

from that we have:

$$Pr\left(k\right)=0iffn-1\le b\le n$$

(9)

$$Pr\left(k\right)=1iffk\ge b+2$$

(10)

In the following, we take the number of corrupt parties b as a percentage of the total number of source parties n. Figure 4 shows how $Pr\left(k\right)$ behaves according to k values with b set to different percentages of n. In

Table 3. Minimal values of k for desired $Pr\left(k\right)$ according to b.

b	10%	20%	30%	50%	70%	90%	95%
$Pr\left(k\right)\ge$
0.8	2	3	4	5	9	29	59
0.9	3	4	4	7	12	38	77
0.95	3	4	5	8	14	46	93
0.99	4	5	7	11	20	64	130
0.999	5	7	9	14	27	89	181
0.9999	6	8	11	18	34	113	230
0.99999	7	10	13	22	41	136	279

, we vary b from 10% to 95% of the total number of source parties n. We set some target values for $Pr\left(k\right)$ to achieve and determine the thresholds of k that ensure the probability $Pr\left(k\right)$ is higher than the desired values:

3.5. Security Proof and Analysis

To demonstrate the robustness and dependability of the proposed system, we present a security proof and analysis in Appendix A. This enables a thorough examination of its security characteristics and renders a comprehensive understanding of the system and its capabilities.

4. Performance Evaluation

In this section, we evaluate our proposed system’s effectiveness by measuring its performance and analyzing its strengths and weaknesses. This evaluation is conducted in two phases. Firstly, the communication and computation overhead complexity is estimated and compared exclusively with fully decentralized reputation systems, as presented in

Table 4. The complexity of reputation computation.

System	Communication	Computation
Pavlov, et al. [6]	$O\left(n^2\right)$ & $O\left(n^3\right)$	Not provided
Hasan, et al. [7]	$O\left(n\right)$	Not provided
Clark, et al. [10]	$\ge O\left(n^2\right)$	Not provided
Our System	$O\left(n\right)$	$O\left(n\right)$

. Subsequently, a series of experiments are conducted on an Intel-Core i7-8750H laptop under the Windows operating system. The experiments were repeated over a total of ten sessions to ensure the reliability and robustness of the results. The results reported in this paper are the average of the ten sessions.

The proposed system efficiently computes reputation scores, as it necessitates only a linear number of messages related to the number of feedback providers (n). Specifically, with a fixed parameter k, the maximum number of messages that need to be exchanged is $6kn-4n+1$, thus the system’s complexity is $O\left(n\right)$. In terms of computation overhead, the system requires the generation of up to $kn-n$ random numbers, the signature and recovery of $kn+2n$ messages, the computation of $kn+n$ addresses, and the encryption and decryption of $kn-n$, which also results in a complexity of $O\left(n\right)$.

In order to simulate the blockchain functionality in our system, we utilized Ganache [61], an Ethereum simulator that enables the development of smart contracts on top of the Ethereum blockchain. Ganache provides all of the necessary remote procedure call (RPC) functions and features and can be programmatically accessed via Python or JavaScript. Our on-chain logic is implemented using two smart contracts written in the Solidity programming language [57], a widely-used object-oriented language on various blockchain platforms, specifically Ethereum. These smart contracts are then deployed to Ganache via Web3.js [62], the Ethereum JavaScript API, which facilitates interaction with Ethereum nodes through RPC.

The first smart contract manages the list of source parties (refer to the listing in Appendix B), while the second simulates the computation and updating of reputation data on the blockchain, as well as performing signature, nonce, and membership verification (refer to the listing in Appendix C). To estimate the computation cost of the RATE smart contract, it was taken off-chain before testing.

The off-chain phase of our simulation was written in JavaScript, utilizing the Web3 RandomHex function for randomness generation, ECDSA for authentication, and ECIES for encryption. It is worth noting that the JavaScript code does not use HTTP or Websocket. Instead, it was run on the Node.js runtime environment [63] as a standalone application. The parameters and settings used in our simulation are outlined in

Table 5. Simulation parameters.

Parameters	Values
Reputation function	The average
Blockchain	Ethereum
Total number of nodes	3000
Subgroups sets	2–300
Rating range	0–100
Shares bitlength	32-bit, 256-bit
ECDSA security	256-bit
ECIES security	256-bit

.

Our simulation verifies the soundness of the proposed system by demonstrating that the generated reputation scores match the ratings’ averages. In addition, we conduct an analysis of the effects of varying parameters, such as the subgroups cardinality k and the shares bitlength, on system performance. Our simulation results provide insight into the practical implementation of the proposed system and its potential performance in real-world applications.

Experiment 1: We know from Section 3.4 that the minimal value of parameter k required to maintain targeted privacy is proportional to the ratio of corrupt parties in the system. Hence, to study the impact of increasing malicious parties’ ratio on performance, it is sufficient to raise k and monitor the execution time. Figure 5, Figure 6, and Figure 7 illustrate the experiment’s results and show a running time quasi-linear in k.

Experiment 2: The second parameter studied was the shares bitlength, which depends solely on the finite field ${\mathbb{F}}_p$ prime number p. Shares are primarily generated randomly in ${\mathbb{F}}_p$, and they have the same bitlength as the parameter p regardless of the rating domain. The experiment consists of changing shares’ bitlength by changing p accordingly and checking any effect on the system performance/execution time. Namely, we set p’s bitlength to 32- and 256-bit, as shown in Figure 5, Figure 6, Figure 7 and Figure 8. The results reveal a mild effect on performance.

5. Conclusions and Future Directions

In this study, we propose a new dynamic, decentralized, and privacy-preserving reputation system. Our system utilizes blockchain technology to store and update reputation data and secure multiparty computation (SMC) to ensure the confidentiality of feedback. By leveraging these technologies, we have developed a fully decentralized system that maintains global reputation information without relying on a central authority. Our system is suitable for general-purpose use cases where nodes can both provide and receive feedback, and has been proven secure under the semi-honest adversarial model. However, future work could investigate the system’s robustness under more advanced threat models, such as covert and malicious attacks. Additionally, our system demonstrates an efficient design, requiring only $O\left(n\right)$ messages and having an $O\left(n\right)$ computation complexity.

Future research directions include addressing other challenges that reputation systems often face, such as oscillation, self-promotion, defamation, and whitewashing. To address these challenges, advanced cryptographic techniques such as data obfuscation, homomorphic encryption, and homomorphic secret-sharing could be explored. Additionally, we plan to investigate the application of reputation systems in location-sensitive networks, such as MANETs and VANETs. In these environments, feedback is often relayed by closely-located nodes, which poses a risk of identity violation. Our objective in these scenarios is to develop a system that enables parties to submit feedback while remaining anonymous.

Another important consideration for decentralized systems like ours is scalability. The number of transactions that a blockchain can handle in a given period is limited, and thus, future work could investigate methods such as sharding or nested blockchains to increase the capacity of our system.