Generalized Secure and Dynamic Decentralized Reputation System With a Dishonest Majority

Reputation management systems are essential for establishing trust among network users. They are tools for reinforcing cooperation and sanctioning malicious behavior. This importance becomes a requirement in decentralized environments such as mobile ad-hoc networks (MANETs), peer-to-peer systems (P2P), wireless sensor networks (WSNs), or decentralized social networks (DSNs) where there is no trusted third party to monitor and enforce good behavior among users. In this paper, we propose a dynamic decentralized reputation system that fits such network characteristics, namely decentralization, dynamism, and openness, without conceding on security. The novel system is a general-purpose system that uses blockchain to gather and supply global reputation information while remaining fully decentralized. Unlike previous works on decentralized reputation systems where reputation information is inconsistent and limited to users’ direct experience and recommendations from peers (neighbors), our system gathers feedback from all over the network and stores reputation information on a distributed ledger fully accessible to all users. In terms of security, the proposed method achieves privacy utilizing secure multiparty computation, a cryptographic primitive that preserves feedback privacy even with a dishonest majority reaching $n-2$ malicious parties while requiring only $O(n)$ messages. The employed techniques enable the system to achieve unique characteristics like consistency, conservation, and verifiability in addition to privacy. The security analysis we provide confirms these properties, and the performed simulation shows the protocol’s effectiveness.

In a world increasingly interconnected, with sustained progress of services and people interacting online, the need for reputation systems is gaining momentum. Indeed, reputation systems help establish trust between users in situations where most online parties are strangers. They enable them to predict who is likely trustworthy even without knowing them. Based on feedback from past transactions, a reputation system typically collects, aggregates, and distributes data about a party, to characterize and predict its future behavior. Consequently, it facilitates community interaction and improves online services efficiency [1].
The associate editor coordinating the review of this manuscript and approving it for publication was Tiago Cruz .
Measuring a user's reputation amounts to estimating the community's confidence in him. Depending on the context, he is expected to behave in a specific manner or perform particular actions. In return, other users give their appreciation of the quality of those actions. If aggregated properly, those appreciations will provide a global score at the community level.
In e-commerce, for example, there are many marketplaces equipped with reputation systems. They collect feedback on products and sellers to help customers decide which product to purchase and from whom. They are good examples of centralized reputation systems. Such systems are possible because of the trust both vendors and consumers put in the marketplace operator.
In MANETs, for example, a party uses his neighbors to route messages. It can collect reputation information on them by observing whether they forward the messages sent through them or not. However, when a new party joins the network, it has no reputation information on others. So in traditional decentralized reputation systems, the new party can ask its peers for their reputation information on a target party and use this as the basis to decide whether or not to interact with it.
One of the major concerns about this approach is feedback privacy. If feedback from some users is exposed eventually when their identities are public, they might be subject to retaliation or attacks and may receive low ratings as a reprisal.
To remedy this situation, several privacy-preserving DRS (PDRS) have been proposed by researchers [5], [6], [7], [8], [9]. In such systems, parties avoid providing their reputation information directly to the requesting party. Instead, they use a protocol that allows them to jointly compute a function based on their rating values (typically the sum or the average). They then send the outcome to the party who made the request. This way, they can keep their ratings private while getting desired results.
However, privacy is not the only concern with traditional DRS. Other problems negatively impact the core functions of these systems, making them ineffective. 1) Availibility: when the reputation information is not evenly available over the network, and thus the system is not fair to all users; 2) Consistency: The reputation information is not the same everywhere and thus inconsistent over the network since users are likely to get different reputation scores for the same target user at the same time based on their relationships and acquaintances; 3) Conservation: The reputation information is likely to be lost with users quitting the network since they store their ratings locally; 4) Efficiency: Another inherent drawback is efficiency, which relates to the fact that the reputation score has to be recalculated from scratch every time a user queries for it, which comes with a consequent cost in computation power and communication. Motivated by these issues, the present work proposes using blockchain as a distributed database for reputation storage and update, jointly with secure multiparty computation for privacy. Unlike the previous works on the subject, the proposed system achieves some important and unique properties. Namely, Availibility, Consistency, Conservation, and Verifiability in addition to Correctness and Privacy.
Some of these properties can seem straightforward if looked at in the context of centralized reputation systems. Nevertheless, in the present context of dynamic decentralized reputation systems, they are challenging. Above that, our protocol is a fully decentralized general-purpose global reputation system, which to our best knowledge, was not achieved before in related works.
The proposed system is distinguished from previous ones by its non-reliance on a querying party to initiate reputation computation since source parties in our system calculate and submit their feedback directly to the blockchain rather than providing it on demand. This solution ensures that the effort is not repeated at each request and saves to a significant extent communication bandwidth and computation power. This paper's contributions can be summarized as follows (see also Fig. 1): • We propose an efficient and dynamic decentralized reputation system by combining secure multiparty computation [10] and non-interactive zero-knowledge proof [11] with blockchain technology [12]. Individual rating statistics are kept private, and only the aggregated reputation is made public under the proposed system. Furthermore, the blockchain architecture ensures that reputation data is consistent and available throughout the network.
• We design a blockchain-based architecture that implements the proposed reputation system to guarantee system transparency and verifiability. The proposed architecture reduces the on-chain storage and computation overhead with an off-chain phase. Security analysis demonstrates the reliability of the proposed system; • After exploring different models used to represent and aggregate reputation in standard scenarios from the literature, we achieve a general-purpose reputation system that complies with the existing models. A system that is not limited, for example, to buyers/sellers or providers/clients settings where nodes are either raters or ratees. Instead, each party in the network has to act simultaneously as a rater and a ratee. The rest of the paper is organized as follows. In Section II, we present some related works. Next, the problem and security definitions are provided in Section III. Section IV introduces the essential building blocks, while a review of the reputation representation and aggregation models in standard scenarios is presented in Section V. The sixth section details the proposed protocol phases, whereas the security analysis and performance tests, insights, and discussions, are provided in Section VII. Lastly, we conclude the work in Section VIII.

II. RELATED WORKS
There are two approaches to privacy-preserving decentralized reputation systems: The first approach concentrates on protecting user anonymity without guarding feedback. Whereas the second focuses on maintaining feedback confidentiality without necessarily hiding identities. Concretely, the distinction between the two is as follows: • User anonymity systems assign to each user one or more pseudonyms that cannot be linked to his true identity so that feedback providers are kept anonymous by having their identities hidden in the system. These systems allow users to issue transactions and provide feedback VOLUME 11, 2023 without concealing it, as it cannot be linked to their identities.
• Feedback confidentiality systems, on the other hand, assign to each user a single pseudonym and keep feedback confidential. They do not conceal who is providing feedback; Instead, they hide the feedback value. These systems, in theory, should not reveal information other than the aggregated reputation score. The present work follows the second approach as it considers it more realistic and practical because complete anonymity is not always possible to achieve in real-world scenarios. For example, on e-commerce sites, even if we can preserve anonymity online, the exchange of physical items sold on them would likely reveal identities. From this perspective, feedback-confidentiality systems are a better alternative to enable users to submit truthful feedback without fear of retaliation.
The major part of traditional works in PDRS (e.g. [5], [7], [8], [9]) consider the setting where a querying party P q wants to interact with a target party P t , but is not sure that P t is trustworthy. Either P q lacks information about P t past behavior, or its experience with P t is too limited or outdated.
N } be the set of parties having reputation information on P t called witnesses or source parties. In this case, P q can consult a selected subgroup of source parties, namely {P i n } (n ≤ N ) that will run a protocol to compute the reputation score of P t securely and send the result to P q .
Following this setting, authors in [5] presented one of the earliest works in the field, with a protocol based on random witness selection and additive secret sharing. The protocol came with three different security strengths and proved the existence of witness selection schemes that guarantee at least two honest witnesses with a high probability. Although the protocol is fully decentralized and designed for general use, it cannot compute and store global reputation scores. Indeed, each party in the system has to store its gathered information locally, and reputation is based only on neighbors' feedback. In addition, the system requires exchanging O(n 2 ) messages at each request for reputation.
Authors in [6] and [8] built upon the work of [5] with the k-shares reputation protocol, respectively for the semi-honest and malicious adversarial model. Their protocol improves communication costs by requiring only O(n) messages. In addition, it maximizes the probability of keeping reputation information private by allowing users to select only witnesses with good reputation scores avoiding those they do not trust.
The prior protocols [5], [6], [8] are not suitable for dynamic networks, and several issues arise when attempting to use them. In such networks, the number of available source parties, i.e., currently part of the network, could be much smaller than if the network was entirely static. Indeed, once a party leaves, all its reputation information is no longer accessible since each party stores its information locally. Also, reputation is likely to be computed with a different set of present parties each time a party requests it. This leads reputation information to get inconsistent and changes at each request.
To alleviate the issue in dynamic networks where parties can enter and quit the network at will, authors in [9] proposed a protocol that allows parties leaving the network to delegate their reputation information to prevent its loss. For privacy reasons, the leaving user has to split the entrusted information over a group of users (secret-sharing) before leaving. Of course, this operation does not go without an increase in computation and communication costs, and if a delegation group member leaves, its information has to be re-delegated. Naturally, recovering and reconstructing the delegated information becomes more challenging with the number of parties involved in inflating and the data becoming fragmented.
However, even if the issue of reputation information loss was partially resolved, it is clear that all the proposed solutions above are incapable of computing and storing global reputation scores.
We can say the same about the work in [13] proposing a decentralized reputation model for VANETs that aims to enable nodes to detect malicious vehicles and avoid interacting with them based on their trust scores. It uses a different model based on the Bayesian filter to measure trust scores accurately, although the reputation information gathered is partial and mostly shared locally.
To structure this section better, we assess and classify related works by the following criteria: 1) Full Decentralization: where reputation systems do not use central entities to collect, compute or serve reputation scores; instead, the information is distributed over parties that share it to evaluate the trustworthiness of potential transaction partners. 2) General-Purpose Reputation Systems are those designed for usage in various network environments. They are not restricted to settings like service providers/consumers in online marketplaces or servers/clients in IoT. Instead, they must fit various networks, including P2P, MANETs, or WSN. 3) Global Reputation Systems are systems that collect ratings from all over the network and aggregate them into global reputation scores accessible to all users. It is worth mentioning that many proposed systems in the literature are not general-purpose systems like the ones mentioned above. They are rather tailored for specific contexts such as online marketplaces [14], [15], [16], or internet of things (IoT) [17], [18], [19], [20] where the network is split into two distinct groups: ratees and raters. Indeed, users in online marketplaces are either consumers, thus raters, or service providers, thus ratees, while in IoT, they are either server nodes or clients. However, in different contexts such as P2P, MANETs, VANETs, DSNs, and WSNs, users have to play both the role of a rater and a ratee.
We highlight that such proposed systems are too specific or incompatible with a fully distributed setting like P2P, MANETs, or WSN.
Among them, we find: PrivBox [21], a verifiable reputation system for online marketplaces. A system designed so consumers can rate retailers and submit their feedback in an encrypted form using homomorphic encryption to a public bulletin board (PBB): a sort of central database. The system makes the reputation information publicly accessible and verifiable without disclosing individual ratings due to the possibility of computing on ciphertexts with homomorphic encryption. However, the protocol leaves the reputation computation task to anyone (seller or buyer) who wants to compute the reputation of a particular retailer. The system employs zero-knowledge proofs to prove that ratings are well-formed.
Another system from [22] called PrivRep and built on [21] uses a similar PBB in addition to a Reputation Engine (RE), responsible for computing reputation from the homomorphically encrypted feedback. The RE is an entity controlled and run by the marketplace that supports the task instead of relegating it to regular users. It reserves the right to reject some of the feedback if judged untrustworthy. PrivRep assumes two central entities: RE for computation and PBB for storage, which undermines its decentralized aspect.
Same for [23] where authors proposed a similar system for the Social Internet of things with a PBB mentioning the possibility of implementing it as a blockchain or as a mirrored server.
In [15], authors proposed a blockchain-based crossplatform reputation system for e-commerce named RepChain; the system interconnects e-commerce platforms and enables them to share their users' reputations through a consortium blockchain. Even though the system is not entirely decentralized, as each platform relies on its centralized entity, the top layer interconnecting platforms is decentralized thanks to blockchain.
Authors in [19] 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.
In the same direction, authors in [24] proposed a twolayered blockchain-based reputation system for VANETs consisting of a local one-day message blockchain and a global vehicle reputation blockchain. The proposed model efficiently manages local traffic information through the local one-day blockchain, reducing the memory overhead of vehicles. According to the vehicle's actions, its reputation score is updated and stored permanently in the global reputation blockchain.
Blockchain has had a wide range of applications due to its outstanding features like security and reliability, especially in distributed settings [20], [23], [24], [25]. Among other applications is Fog computing, where blockchain may achieve secure decentralized reputation systems and identity management [26].
Authors in [20] proposed a system for the Internet of Things (IoT) that considers geospatial information in reputation management as the trustworthiness of a device can be affected by many factors, including its geographical location. The proposed solution has a cloud-fog-edge architecture where the fog layer employs a blockchain to form a decentralized network among fog nodes allowing decentralized and transparent management. The location-based system part stores geographical information in Smart Contracts and enables reputation values to vary according to geographical location.
To our best knowledge, From literature assessment and classification of related works according to five criteria, namely: Full Decentralization, General-Purpose, Global Reputation, Privacy, and employed Technologies (The comparative study is summarized in Table 1), we can confidently say that part of the related works are fully decentralized VOLUME 11, 2023 reputation systems that are general-purpose but do not maintain global reputation scores and rely on locally stored information. Their reputation information is partial and inconsistent over the network because it is limited to users' direct experience and recommendations from neighbors and acquaintances. The other part of related works is proposed in specific settings that achieve global reputation and some form of decentralization but are not general-purpose systems. Our objective in this work is naturally to fill the gap in global reputation systems that are general-purpose and fully decentralized.

III. PROBLEM FORMULATION
In this section, we formulate a model for our system and present the security and adversarial model.

A. SYSTEM MODEL
In our system, there are two entities, namely users and the blockchain. Users have two roles to play: • Regular User uniquely identified by its public key pk or its address a can interact with other peers and leave a rating score for whom he interacted. He maintains a lightweight copy of the ledger locally; • Validator or Miner is a regular user with a higher reputation score that enables it to contribute to maintaining the public ledger with other miners based on a consensus protocol (see IV-A). At a high level, the system works as follows. Parties join the network by generating a pair of keys associating the public key to a unique identifier like a Media Access Control address, an IP, or a hash. All communication between parties is done via secure channels. The latter are emulated by employing signature and encryption. Specifically, we use ECDSA signature [27], and ECIES encryption schemes [28].
Parties can perform actions specific to the network and interact with each other. At the end of the interaction between, for example, two parties A and B, B will get an authenticated piece of data from A attesting to the exchange. It can then rate A accordingly by joining its source parties list, computing a joint rating with other peers in the list, and submitting it to the blockchain. Finally, rating transactions for the same party aggregate as a reputation score on the blockchain.

B. ADVERSARIAL MODEL
In the semi-honest adversarial model, users always follow the protocol. They execute the protocol according to the specifications and do not deviate from them. However, they may passively attempt to learn the inputs of honest users by using intermediate information received during the protocol execution or any other information they can gain through legitimate means.
Under the malicious model, things are different. Users may deviate from the protocol and attempt actively to achieve their objectives through arbitrary behavior and extra-protocol activities following diverse strategies.
A dishonest user may act alone or in agreement with other malicious users to achieve his goals. When multiple users of the same type work together, we refer to them as collusion. We call an adversary any coalition of dishonest users.
The present system is secure in the semi-honest and malicious adversarial model. For the on-chain phase, i.e., executed on the blockchain, the system is safe from any adversary with computation power/stake below 51% of the network. For the off-chain phase, it is secure with a dishonest majority up to n − 2.

C. SECURITY OBJECTIVES/REQUIREMENTS
The main security objectives of the proposed system are privacy and integrity. Privacy consists of preserving the confidentiality of feedback and any information related to it, while integrity aims to maintain the functionalities of the reputation system unaltered. It includes, for example, preventing a malicious user from manipulating the reputation aggregation function to forge an unmerited good reputation. In the following, we enumerate privacy and integrity sub-objectives in detail, as well as some properties essential to the system: • Privacy This property guarantees feedback confidentiality protection so that it is neither disclosed explicitly nor derived from any public or intermediate information gained by the adversary during the interaction. Even more, the adversary is unable to learn any additional information beyond the final reputation score; • Correctness As the reputation system relies on regular users and validators to perform some computation. Correctness property requires that the adversary is unable to mislead the system to erroneous results; • Authorizability. The requirement is that only users who have had an interaction with the ratee can rate him. This property prevents users who had not transacted with a ratee from assigning him unjustified feedback for some motive, whether for tarnishing his reputation or for false promotion ( attacks such as bad-mouthing and selfpromotion); • Verifiability The requirement that any user should be able to identify all published feedback linked to some identity and verify its basis on authentic transactions from real partners. Moreover, he could verify that the reputation score was computed correctly from the related feedback; • Availibility guarantees that every party on the network can access all reputation scores at will. For example, malicious users can attempt to take down the system by different means and attack or prevent honest users from accessing it. The system has to grant all legitimate users equitable access to public reputation scores at any time; • Consistency is the requirement that if different parties request a reputation score at the same time, they get the same reputation score everywhere in the network until new ratings come into the system if we take into account the propagation time; • Conservation This property requires that even if a party leaves the network, its ratings have to remain part of the system and that the reputation score is a function of all the previously submitted ratings in the network.

IV. BUILDING BLOCKS
In the following, F denotes the finite field F p with p a sufficiently large prime number.

A. BLOCKCHAIN
A blockchain is similar to a distributed public database. Every user can read from this database, but it takes more to write to it. For that, users have to reach a majority consensus over the network before the writing is accepted [29]. Any action that modifies this database is called a transaction. Transactions are typically gathered and recorded in the form of blocks and then broadcast among all users. Once the network reaches a consensus over a block and accepts it, it becomes difficult to alter it. Blockchain is reputed for recording transactions efficiently in a verifiable and permanent way. For this reason, it is considered an append-only database. Blockchain can also be seen as an ordered list of blocks (B) (0≤i<l) (see Fig. 2) chronologically constructed from the first block B (0) called genesis block to the last block B (l) which is the current valid block. Other blocks will add to this list in regular periods. The result of all transactions in all blocks at a given moment constitutes the state of the blockchain.
Blockchain is resistant to modification by design. It is typically managed by a P2P network adhering to a communication protocol.
A transaction T is a single instruction used typically to transfer a sum of coins (virtual money) securely. Each block B (i) is composed of the header H (i) and the body that comprises a series of transactions T (i) = (T 1 , . . . , T n ) in the form of a Merkle tree. The header H (i) includes a collection of relevant pieces of information.
As mentioned above, the state is the resultant of all transactions in all blocks at a specified time. It is an auxiliary database that summarizes the blockchain state at a given moment. The state database introduced with Ethereum [27], [30] is a modified Merkle tree implemented as a mapping between parties' addresses and their account states. It is maintained, updated, and linked to every new valid block (see Fig. 3). Unlike Ethereum, Bitcoin does not implement an equivalent structure [31].
We denote the state database σ and use a party address a to reference its account denoted by σ a . In our context, the account state will include, among others, the following fields relevant to our system: l [ ]. One can implement these additional fields easily using Smart Contracts on existing blockchains that support them. However, they can also be implemented as standard state account fields and integrated directly into the blockchain framework. In the present work, we adopt the latter approach throughout the paper, except for the performance evaluation section, where we use smart contracts, as they lend themselves easily to experimentation.

1) CONSENSUS
Creating new blocks is controlled by a mechanism that varies between blockchain technologies. The Proof-of-Work was the first mechanism used to reach consensus [32] on newly created blocks. A concept introduced with Bitcoin [12] and followed by several alternative coins launched using similar ideas.
The mechanism of Proof-of-Work allows miners to write to the blockchain only if they prove that they did a certain amount of work. The work consists of an extensive search for partial collision using hash functions. This mining process demands a lot of computing energy [33].
With the advent of PPCoin [34] further developed by BlackCoin [35], NXT [36] and NeuCoin [37], a new family of systems was born replacing the Proof-of-Work with the concept of ''Proof-of-Stake'' From its side, Proof-of-Stake enables every participant to randomly gain the right to write to the public database with a probability proportional to his stake, i.e., the number of coins he owns. This approach cancels the extra computing cost of mining and leads to a much faster block-creation process. It seems perfectly reasonable today to maintain distributed consensus using Proof-of-Stake. The thing we consider more appropriate in our context than using Proof-of-Work.
During the block creation process, the validators perform various tasks. Among them the verification and recording of new transactions. A new block typically contains transactions that have occurred since the last block, and when effectively added to the blockchain, the underlying transactions are definitive. Subsequently, all the concerned accounts states are updated to reflect the changes.

B. MESSAGE AUTHENTICATION CODE
Loosely speaking, a message authentication code (MAC) is a piece of data used to authenticate a message. Like digital signatures, its purpose is to confirm that the message came from the stated sender (authenticity) and has not been changed (integrity). It allows the receiver to detect any change to the message content. However, unlike digital signatures, MAC values are generated and verified using the same secret key, which implies that the sender and receiver must agree on a key before initiating communications.
Formally, a MAC scheme is a triple of polynomial-time algorithms (Gen, Mac, Verif) such that: • Gen(1 λ ) is the key generation algorithm that takes λ the security parameter as input and samples a key k ∈ K from the key space uniformly at random k ← Gen(1 λ ); • Mac k (m), the Mac algorithm returns a tag t = Mac k (m) on input key k ∈ K and message m ∈ M ; • Verif(k, m, t) is the verifying algorithm that takes an input k ∈ K , m ∈ M , and t ∈ T , verifies the authenticity of the message and returns accepted when the message and the tag match t = Mac k (m) and rejected otherwise; • The following equality holds. A MAC scheme is said to be secure (unforgeable) if for every polynomial time adversary A: where A Mac k (·) denotes that A has access to the oracle Mac k (·), and Query(A Mac k (·) , 1 λ ) denotes the set of the queries made by A on Mac() knowing λ. The function ϵ(λ) is negligible in the security parameter λ, i.e., for every nonzero polynomial function poly() there exists λ 0 such that |ϵ(λ)| < 1 poly(λ) for all λ > λ 0 .

1) ONE-TIME MAC
We refer to a MAC as a one-time MAC if it uses the key at most once. It can be built from primitives like universal hashing and pairwise independent hash functions.
The simplest one-time MAC from pairwise independent hash functions is defined by a random key k = (a, b), and a MAC tag Mac k (m) = (am + b) mod p, where p is prime.
It is shown that one-time MACs are unconditionally secure and that even quantum resources do not offer any advantage over them [38].

C. SEMI-HOMOMORPHIC ENCRYPTION
In this subsection, we introduce the Semi-Homomorphic Encryption Scheme (SHE). A cryptographic primitive that satisfies our system needs in terms of homomorphic encryption while being lighter and more efficient than other homomorphic primitives. SHE [39] is a public-key cryptosystem that satisfies a relaxed version of the additive homomorphic property. SHE is a tuple of algorithms (Gen, Enc, Dec) where: • Gen(1 λ , p) is a randomized algorithm that takes as input a security parameter λ and a modulus p. It outputs a public/secret key pair (pk, sk) and a set of parameters P = r of random integers such that ||r|| ∞ ≤ σ for some σ < R except with negligible probability. Finally, G is the domain of ciphertexts, an additive abelian group; • Enc pk (x, r) is a deterministic algorithm that takes as input an integer x ∈ Z p and a vector r ∈ Z d and outputs a ciphertext C ∈ G. We sometimes write Enc pk (x) when it is not important to specify the randomness explicitly; • Dec sk (C) is a deterministic algorithm that takes as input a ciphertext C ∈ G and outputs with probabilities taken over randomness in Gen and Enc, and ϵ(λ) a negligible function.
SHE is IND-CPA-Secure (i.e. achieves indistinguishability under chosen plaintext attack) if for all probabilistic polynomial time adversary A = (A 1 , A 2 ), the advantage of A on the following experiment verifies: with the probability taken over randomness in Gen, Enc, and A.
Paillier Cryptosystem: We obtain a semi-homomorphic scheme straightforward from Paillier's cryptosystem [40] by setting the adequate parameters: • The secret key as two large primes sk=(p 1 , p 2 ), and the public key as pk=N =p 1 p 2 , and M =( The decryption function is simply redefined as Dec ′ (c)= Dec(c) mod p to get the reconstructed plaintexts modulo p. We highlight that the Paillier cryptosystem is written a bit differently from the above SHE definition, which writes G additively, while Z * N 2 is written with multiplicative notation. Also for Paillier we have Enc pk (x, r) + Enc pk (x ′ , r)= Enc pk (x + x ′ , r · r ′ ) instead of Enc pk (x + x ′ , r + r ′ ). However, this makes no difference.

D. COMMITMENT
Commitment schemes are common ingredients in cryptographic protocols. As their name suggests, they are used to enable a party to commit itself to a value while keeping it secret [45]. Once a party has committed to someone, it cannot change it later when the commitment is ''opened,'' and other parties cannot gain knowledge about it before the opening. Commitment schemes are the digital form of non-transparent sealed envelopes.
A commitment scheme is a two-phase protocol with two players: a sender S and a receiver R. It must satisfy two requirements to be secure: (1). Hiding (or Secrecy): At the end of the Commit phase, the receiver R does not gain any knowledge of the secret.
(2). Binding: Given the commitment from the Commit phase, there exists at most one value that the receiver can accept in the Open phase as a legal opening of the commitment.
The commitment scheme presented below for the present system uses a hash function H (a Random Oracle) and some randomness: He accepts if and only if this check passes.

E. SECRET SHARING
Secret sharing is a method for splitting a secret among a group of parties such that they cannot reconstruct the secret unless a sufficient number of them unite. A dealer in a secret sharing scheme gives each party a share. But a single one is of no use on its own. For example, a t-out-of-n (t, n)-secret sharing scheme is secure if it distributes n shares so that any subset of parties with less than t shares cannot reconstruct the secret. Moreover, it cannot gain more information about it. In our context, parties use the secret sharing technique to make joint computations on their private ratings without revealing them. Particularly two techniques are used further in SMC (see IV-G): • The first one is an authenticated version (see IV-B) of the trivial (n, n)-additive secret sharing scheme defined as follows: For a secret x, the dealer D samples randomly x (i) $ ← −F for 1≤i≤n − 1 and sets the n th share x (n) such that The result is an (n,n)-additive secret VOLUME 11, 2023 sharing of x: • The second technique used in our system based on a semi-homomorphic encryption scheme (see IV-C) allows two parties to secret-share the product of their inputs without revealing them. It works as follows: One party P 1 sends an encryption Enc pk 1 (a) of its input a under its own public key to another party P 2 , which replies by C=b·Enc pk 1 (a)−Enc pk 1 (x 2 ), where b denotes party's P 2 input, and x 2 is chosen at random. Since a semi-homomorphic encryption scheme supports the multiplication of a known value with a ciphertext, hence the decryption of C is x 1 =b · a − x 2 , which makes [a · b]=(x 1 , x 2 ) an additive secret sharing of a · b.

1) AN AUTHENTICATED SECRET SHARING
The idea behind authenticated secret sharing is to use one-time MACs to prevent parties from lying about their shares when they are supposed to generate them correctly.
In this regard a random key κ∈F is issued, and a MAC for a∈F defined by Mac κ (a)=κ · a mod p is used. For some parties P 1 , . . . , P n , if κ is the MAC key and [κ]=(κ (1) , . . . , κ (n) ) its secret sharing, we assume that every party P j 1≤j≤n keeps its share κ (j) secret and that κ the global key is unknown to all parties. They can easily achieve this result by generating their random shares independently and committing to them so that κ results naturally as the sum. The protocol Rand does exactly that: [κ]← Rand .

Protocol 2:
The Protocol Rand 1) Every party P i samples r (i) $ ← −F commit to it and keeps it private. 2) Take r= n i=1 r (i) such that [r]=(r (1) , . . . , r (n) ) and r is random and unknown to all parties until the shares are opened.
Definition 0.1: We call an authenticated secret sharing of x∈F under a global key κ the ordered set: , and κ= n i=1 κ (i) . If a party P i , for example, wants to generate the authenticated shares for its private input x, then it has to share x, m(x) under κ: • For κ, nothing needs to be done. It is already shared since every party P j has its private key share κ j . If not [κ]← Rand is executed.
• Sharing x is also straighforward like explained above [x]=(x (1) , . . . , x (n) ) such that n i=1 x (i) =x. • For m(x)=Mac κ (x)=κ · x, we know for sure that P i cannot share it on its own since it does not know κ.
So it needs some interaction and the semi-homomorphic technique mentioned above: For that each party P j sends an encryption Enc p k j (κ j ) of its key share under its own public key p k j to P i , which replies by c j =x · Enc p k j (κ j ) − Enc p k j (e j ), where e j is chosen at random. Since semi-homomorphic encryption schemes allow the addition of ciphertexts and multiplication of ciphertexts by cleartext, hence if P j decrypts c j , it gets Dec s k j (c j )=x · κ j − e j . P j then sets its share to =x · κ. This leads to [m(x)]= (m(x) (1) , . . . , m(x) (n) ) an additive secret sharing of m(x)=x · κ.

F. ZERO-KNOWLEDGE PROOFS
A Zero-knowledge (ZK) proof allows a verifier V to check the validity of a statement claimed by a prover P without revealing anything other than the claim being true.
An example of ZK proof of knowledge is the Schnorr-like protocol based on the standard 3-move − protocol. Its goal is to prove knowledge of x in a field F , such that f (x)=y without revealing x. The protocol works as follows: 1) The prover P samples a random s $ ← −F and sends a commitment a=f (s) for s to the verifier.
2) The verifier V then samples a random c $ ← −F and sends it to P.
3) P replies with z=s + c · x. Finally V checks whether f (z)=a + c · y. where f is homomorphic for the field operations.
• Correctness the protocol is correct if f is homomorphic for the field operations.
• Honest-Verifier Zero-Knowledge or Security of the Prover is achieved by simulating (a, c, z) from any c by sampling z $ ← −F and computing a=f (z) − c · y. • Special Soundness or Security for the Verifier is obtained by extracting the secret from two different transcripts (z, c), (z ′ , c ′ ) with c̸ =c ′ which can be done by computing x=(z − z ′ ) · (c − c ′ ) −1 (the operations are possible in a field). The Non-interactive Zero-Knowledge (NIZK) [11] version of this scheme is achieved through Fiat-Shamir transformation [46] using a secure cryptographic hash function (Random Oracle Model). Instead of the verifier issuing the challenge c, It is simply redefined as c=H(pp||y||a), where pp is some public parameter. The hash function H should be a secure cryptographic hash function, e.g., SHA or SHA3, with a bitlength at least equal to the order of the considered subgroup.  sends (a, c, z) where z=s + c · x.
2) The verifier V computes c=H(pp||y||a) and checks whether f (z)=a + c · y.
NIZKPoK is used extensively in our system with function f set to the Enc pk (), the encryption algorithm of a SHE protocol.

G. SECURE MULTIPARTY COMPUTATION
Secure Multiparty Computation (SMC) allows a group of parties to compute a function jointly over their private inputs. For some parties P 1 , . . . , P n , each party P i holding a secret input x i and f an agreed-on function that takes n inputs, An SMC protocol enables P 1 ,. . . ,P n to compute y=f (x 1 , . . . , x n ) while satisfying the following conditions: • Correctness: the protocol computes the correct value of y; • Privacy: The parties P 1 , . . . , P n cannot learn additional information from the protocol but y. Usually, the desired function f is represented by the equivalent boolean or arithmetic circuit.
Currently, to realize SMC one has two paradigms to choose from, secret sharing [47], [48], [49], [50] and garbled circuits [51], [52], [53]. Both paradigms come with their strengths, and both have their lines of development. Since secret sharing is currently the most suitable to evaluate arithmetic circuits, we adopt it for our protocol.
The proposed system uses a general SMC protocol in the preprocessing model [47], [48], [49], [54] built upon the blocks presented above. It is a two-phase protocol inspired by the Overdrive protocol [49], an efficient improvement of SPDZ protocols [47], [48]. The preprocessing phase executed individually precedes the online phase that involves interaction. From its side, the online phase where players share inputs via additive secret sharing uses cheap informationtheoretic primitives. While in the other side, the preprocessing phase uses a homomorphic encryption technique to generate random triples independently from inputs for further use in the online phase.
The SMC protocol guarantees privacy and correctness by using commitment and zero-knowledge proofs and authenticating shared values with information-theoretic MACs as presented in subsection IV-E1.
Formally, every P i executes [[·]] ·Input (see protocol 5) on its private input x i ∈F, to generate and share [[ (1) , . . . , m(x i ) (n) , κ (1) , . . . , κ (n) ) the authenticated secret sharing of x i , where each player P j s.t. 1≤ j≤n holds a share tuple [[ , and κ= n j=1 κ (j) . In the online phase, the main task is to evaluate a circuit over secret inputs, which the parties do by performing operations like addition and multiplication on authenticated shared values, c.f., protocol 6. To ̸ =0 then abort and output ⊥; otherwise continue.

Protocol 5: [[.]]
-Initialize: Each party P i does the following: 1) Sample a MAC key κ (i) $ ← −F; 2) Initialize two instances of NIZKPoK with every other party P j (one as prover, one as verifier), receiving ( pk i , sk i ) and pk j ; 3) Using NIZKPoK , send an encryption Enc κ (κ (i) ) to every other party. -Input: On input x j from P j : 1) For the input x j , P j samples randomly x (i) j $ ← −F for each party P i . Then P j sets its corresponding share 2) For every party P i : a) P j computes C  -Check: All parties run MACCheck protocol with y, m(y) (i) , κ (i) .
There is a clear distinction in SMC operations between public and private operands. We can always perform calculations on public operands the usual way. However, private operands need to be shared and authenticated before any operation. After secret-sharing private operands between parties, a party can perform calculations only on the shares it got and thus cannot get the global result. Instead, it gets a partial result that is meaningless on its own, but if gathered with others, it serves to reconstruct (open) the global one acting as a share for it. ; m(a) (1)
As mentioned above, operations with only public operands do not require special treatment. Only calculations that involve private operands are relevant for SMC. We concentrate on the following section on this type of operation when reviewing reputation aggregation functionalities by identifying relevant parts and leaving others as is.

V. REPUTATION REPRESENTATION AND COMPUTATION IN USUAL SCENARIOS
In the following, we investigate formats and models used to represent and compute reputation from ratings in typical scenarios. We aim to determine precisely the types of functionalities a reputation system in such scenarios has to calculate over ratings and present how the proposed protocol implements them.
From the SMC viewpoint, ratings are inputs, and reputation is output. However, the SMC protocol is more costly than regular computation. For this reason, we prefer isolating parts of these functionalities that must be securely computed using SMC to preserve privacy from parts that can be computed publicly (in clear) without compromising privacy.
Regarding rating representation, several formats are employed in the literature to describe and exchange rating information. The following types are used traditionally to represent them: • The Binary format is used in the case ratings are either positive or negative regardless of their values, and they are stored using boolean values [56], [57], [58].
• Discrete is employed when ratings take several values on a scale. They are usually stored using discrete integer values [58].
• Continuous, where the information is stored as a floating point number [57], [58].
• String: The information is stored in textual form, allowing a wide range of data to be maintained [56], [59]. Regarding reputation computation, there are several approaches to aggregating ratings into a reputation score. The simplest way consists of counting the number of positive and negative ratings for an entity and summing the two numbers [60]. The final score serves to rank all entities in the system.
A slightly better way is to average all ratings to get a single score for each entity. Furthermore, weighting ratings can enhance this approach by providing more importance to, for example, recent ratings or those from more reputable sources [61]. Additionally, normalization can be used to evaluate reputation on a specific scale.
In the following, we sum up the different approaches in the literature and specify how our protocol applies to each one:

A. COUNTING
Counting, as introduced above, relies on standard techniques like summation, averaging, and weighting to compute reputation. Some authors [62] adopt a more natural way for humans to represent ratings [60] like Very Trustworthy, Trustworthy, Untrustworthy, and Very Untrustworthy. Such representations are hard to work with before converting them to numerical values. If converted, the counting method is then applied (average, for example), and the result is converted back using look-up tables.
According to the adopted counting method, applying SMC to compute either the sum, the average, or the weighted average of parties' private ratings is straightforward. It does not need any adaptation or change. It suffices to run [[.]] (protocol 5) on ratings as inputs.
We can verify easily that w t =w (1) t +w (2) t +w (3) t . For the general correctness demonstration, the reader can refer to section VII.
Next, all P i for 1≤i≤3 commit and broadcast w (i) t , and compute w t by executing [[·]] · Open(), which calculates w t = w (1) t + w (2) t + w (3) t after requiring parties to commit to their shares w (i) t before broadcasting them. As w (i) t does not reveal any information about x i for 1≤i≤3, it is safe to broadcast them. However, to prevent parties from changing w (i) t values according to others' values during the protocol execution commitment is required.
The last step for parties before accepting w t as the correct reputation score is to verify that no party has sent false shares or wrong values to manipulate results or induce other parties in error. For that every party P i calls MACCheck on w t , m(w t ) (i) , κ (i) . If the check is positive, they are sure that the computation is correct.
The Counting scenario is summarized in table 2.

B. PROBABILISTIC
Another aggregation method involves using a probability model to predict future behavior from the knowledge of prior events by fitting the latter as input and computing the likelihood of a hypothesis to hold like ''a party x will behave correctly'' [58], [61], [68], [69], [70], [71]. Probabilistic systems are generally based on the Bayesian model. They take binary ratings as input (i.e., positive or negative) and compute reputation scores by statistically updating a beta probability density function (PDF). The beta distribution takes two free parameters, α, and β, respectively, the number of positive and negative feedback. The reputation score is the tuple of Beta PDF parameters (α; β), or the Expectation value of the beta PDF, and optionally accompanied by the Variance or a Confidence parameter. Besides, the tuple (α; β) must be stored and updated with new rating occurrences. Otherwise, we cannot update the Expectation value or the Variance without the two parameters. The Beta PDF denoted by Beta(p|α; β) is expressed using the gamma function as: where 0≤p≤1 and α; β>0. The probability expectation of the beta distribution is given by: E(p)=α/(α + β).
From the above, we can represent and store the reputation score as the tuple (α; β) without deviating from the adopted approach or losing privacy. Since the tuple (α; β) does not reveal any of the individual ratings, the Beta PDF can be applied to it by the system in a second step as convenient. On the contrary, if we store just the beta PDF value without the tuple (α; β), it will be impossible to recalculate its value when new ratings enter the system. Let us encode ratings as vectors in F 2 , namely, the positive rating as (1, 0) and the negative as (0, 1), and then take (α; β) as the sum of previous ratings; therefore α and β correspond to the number of positive and negative feedback respectively. The aggregation function here is simply the sum.
We also highlight that the SMC protocol applies to vector inputs without any change. The only exception is for randomly generated shares that now have the form: x (i) respecting the operations in F 2 : A summary of the probabilistic scenario is presented in table 3.

C. FUZZY
Some authors [74], [75], [76] also explored Fuzzy logic for aggregating reputation, using fuzzy rules to combine several criteria in the reputation score. Fuzzy logic is used to process ratings while allowing these systems to work with uncertainty [60], [61]. For example, the FuzzyTrust [74] system aggregates local trust scores collected from all peers to produce a global reputation for each peer. The system uses fuzzy inference to get the reputation aggregation weights from three variables: the peer reputation, the transaction date, and the transaction amount. It calculates the global reputation according the following formula: R i = j∈S w j t ji j∈S w j where R i is the global reputation of peer i, S the set of peers with whom peer i has transacted, t ji the local score of peer i rated by peer j, and w j the aggregation weight of t ji .
We note that the aggregation function, in this case, is R i , the weighted average of {t ji } j∈S . The system infers aggregation weights {w j } j∈S using fuzzy logic from three public variables, which makes them also public, unlike the local scores t ji meant to stay private.
Based on the above, SMC can be applied without change. The Fuzzy scenario is summarized in table 4.

D. FLOW
Flow computes reputation by processing the flow of transitive trust [3], [60], [61], [78], [79], [80]. For instance, in [3], each peer i can store the number of satisfactory transactions it has had with peer j as sat(i, j), and the number of unsatisfactory ones as unsat(i, j). Then s ij is defined as s ij =sat(i, j) − unsat(i, j). The local trust value s ij , is then normalized as c ij = max(s ij , 0) to ensures, all values are between 0 and 1. The peer i then aggregates the normalized local trust values of his friends towards j, t ij = k c ik c kj , by asking for their opinions and weighting their opinions by the trust he places in them.
The system enables a peer i to extend from his acquaintances to his friends' friends and beyond. At each circle of friends, the local trust scores they give are weighted by the trust scores their intermediate friends put on them. The Eigentrust system has modeled this transitive process elegantly using matrix calculation.
Of course, this is not a global reputation score in the proper sense of the word, but the more the circles of friends are large, the more accurate and stable the score obtained.
The very reason for the existence of this system is the inability to aggregate local scores directly into a global score and the absence of the necessary infrastructure for that. Otherwise, it would be more than enough to take t j = k t k c kj if the system allowed it. Therefore, the reputation aggregation function of such a system reduces to a weighted average, and even the transitive aspect will disappear if the system supports global aggregation. Also, the approach for SMC remains the same in this case.
We present a summary of the Flow scenario in table 5.

E. OUR APPROACH FOR REPUTATION AGGREGATION
Let us assume in the beginning that a party a has formed an opinion on the behavior and quality of action of a target party t. We state that whatever the approach adopted for the reputation aggregation and the type used to represent the rating of t by party a, we can always convert it to a numerical form like shown above and consequently encode it as a string of bits with adequate precision, e.g., 32bits or 64bits. This form lends itself easily to operations like summation, averaging, weighting, normalization, and other operations. At this end, we choose p big enough to encode all possible ratings and a wide range of shares values as elements of Z p (take p>2 32 , p>2 64 ).
Let ρ (a) t ∈Z p denote party's a rating on party t. A party a is said to be a source party for party t if a has feedback on t. The set of all source parties of a party t is given as S t . Definition 1.1 (Reputation): . Let S t ={a 1 ...a n } be the set of source parties t. Let Rep denote the reputation function, such that Rep:(Z p ) n →R. The reputation of party t is given as:

VI. THE REPUTATION PROTOCOL A. PROTOCOL OUTLINE
The protocol assumes that after the target party performs some action, the interacting parties will get a piece of data denoted Trace as proof of interaction. They can join the list of source parties and compute reputation jointly based on their ratings based on the quality of that action. Afterward, they submit the resulting score to the blockchain for integration.
If a party is new or has a bad reputation, it cannot join the list of source parties and thus cannot rate other parties. Of course, it can continually improve its reputation by behaving well and receiving positive feedback from its peers. However, only parties with reputation scores exceeding a predefined threshold Tr can rate others.
The protocol comprises three phases presented below; see also, Fig 2) The miner adds the address of a party requesting to join the list of t's source parties to σ (t) l [ ] if: a) the Trace it sent is valid and not used before in previously recorded JOIN transactions; b) and its reputation score is >T r ; 3) Each party gets an assigned subgroup of source parties according to its order in the queue.

2) PHASE 2: SECURE MULTIPARTY COMPUTATION
Any source party can initiate this phase by requesting interaction with other parties in U or issuing the transaction at the end. Let us refer to that party by a 1 for simplicity and to the set of selected parties by U ={a 1 , . . . , a k }.

B. PRIVACY
Suppose we have an adversary A, a coalition of dishonest parties A={a i 1 , . . . , a i m } from the group of participating in the protocol {a 1 , . . . , a k } and A is seeking to uncover the private input x i of the honest party a i . During the execution of the protocol till the end, every party a j ∈A gets from a i the following information: {x i =x i · Enc pk j (κ (j) ) − Enc pk j (e (j) i ) and y=Rep(x 1 , . . . , x k ). A question arises at this level. What can a j ∈A learn from this information either individually or as a coalition? It can of course decrypt C (j) i . At this stage it is useful to highlight that x (j) i and e (j) i are uniform random numbers from F that a i has generated independently from x i . In addition e (j) i are unknown but to {a j } j̸ =i . Therefore we can say that: It is not feasible to reconstruct x i from less than the k shares {x (j) i } 1≤j≤k which follows from the fact that the secret sharing scheme is an k out of k scheme.
The adversary cannot recover i is unknown to him and it is blinding x i · κ (j) . The probability for him to make the right guess is small ≃1/p.
There is a case where only one party of the k parties is honest. Let us say it is a 1 . In this case the adversary A={a 2 , . . . , a k } can deduce x 1 just from his known ratings {x 2 , . . . , x k } and the outcome of the computation Rep(x 1 , . . . , x k ).
Therefore we can state: Theorem 2: The Protocol grants feedback privacy in the presence of at least two honest parties.

C. AUTHORIZABILITY
We enforce authorizability by requiring a valid receipt from the rater, proving that an interaction occurred between him and the ratee. We denoted it Trace. As mentioned above, it contains interaction-specific data, a timestamp, and signatures. The rater includes Trace in the JOIN transaction before he can join the list of source parties. As a result, a party that has not interacted with t cannot join its list or rate it. Furthermore, it cannot use the same receipt multiple times because it is registered on the blockchain the first time it does. An advantage of the blockchain property of preventing double-spending.

D. VERIFIABILITY
Verifiability is also a crucial property in a blockchain. It allows any user to get the full copy and follow from the genesis block to the last one, verifying that every transaction is executed correctly and reflected in accounts. Another fact is that each new block is invalid unless the network majority (consensus) verifies and accepts it. This possibility remains available, particularly for ratees and newcomers to the network.

E. AVAILIBILITY
The blockchain relies on a P2P network. If a peer fails, it does not affect others as the data is duplicated over the system, and all validators have complete copies of it. On the other hand, regular nodes maintain short copies comprising headers and the state that contains the comprehensive list of accounts and reputation scores.

F. CONSISTENCY
Every new block validator must broadcast it to the community for verification and acceptance. If the majority accepts it, then it is considered valid. As a result, every party has the latest copy of transactions and reputation information, observing a propagation time. VOLUME 11, 2023 G. CONSERVATION The property of conservation in the system is obtained straightforwardly from a blockchain characteristic. It relies on the property of immutability and the fact that all transactions on valid blocks cannot be altered or deleted, including rating transactions.

H. WHICH PARAMETER k FOR THE SYSTEM
Running secure multiparty computation simultaneously with all the n source parties is demanding, especially if n is a large number. Even more, in dynamic networks, where parties can enter and leave for diverse reasons. Besides, the task requires O(n 2 ) message, which we reduce significantly by dividing the source parties into subgroups that do not exceed a fixed number of parties k with k a fixed parameter overall in the system.
From the discussion above in theorem 2, we know that privacy holds if there are at least two honest parties among the k parties in each subgroup. The probability to have, at least two honest parties participating in the subgroup is equal to / n k if the parties are selected in a uniform random way. k is the number of participating parties, n is the total number of source parties, and b is the total number of corrupt parties. Let Pr(k) be this probability according to the value of k: In the following, we take the number of corrupt parties b as a percentage of the total number of source parties n. Figure 5 shows how Pr(k) behaves according to k values with b set to different percentages of n. In table 6 we vary b from 10% to 70% of the total number of source parties n. We set some target values for Pr(k) to achieve and determine the thresholds of k that ensure the probability Pr(k) is higher than the desired values:

VIII. PERFORMANCE EVALUATION
This section evaluates our system to validate its effectiveness in two ways. The first way estimates the system complexity component by component and provides its overall complexity (see Table 7).
The second way simulates the protocol and measures its performance. Several simulations were conducted to assess the system in different scenarios by varying parameters to demonstrate its strengths and weaknesses. All simulations were executed on an Intel(R) Core(TM) i7-8750H CPU laptop and repeated over 100 sessions. The results in this paper retain the average of the 100 sessions.
To simulate the blockchain, we used Ganache [82], an Ethereum simulator that enables application development on Ethereum (called Smart Contracts). Ganache includes all remote procedure call (RPC) functions and features and can be used programmatically via Node.js [83]. We implemented our on-chain logic using two Smart Contracts written in Solidity language [84], an object-oriented programming language used on various blockchain platforms, notably Ethereum. Then, we deployed the Smart Contracts to Ganache via Web3.js, the Ethereum JavaScript API [85], which enables interaction with Ethereum nodes using interprocess communication (IPC).
For the off-chain phase written in JavaScript, we used Web3.Utils.randomHex for generating randomness, ECDSA for authentication, and ECIES for encryption. We highlight that the JavaScript code does not rely on HTTP or Websockets. It is instead run on the Node.js runtime environment as a stand-alone application. The parameters and settings information for our simulation are shown in Table 8.
Firstly, by simulating the system, we verify that the produced reputation scores match the ratings' weighted average. This way, we demonstrate that the protocol is sound and outputs accurate results. Then, we study the effect of varying parameters like subgroups cardinality k, shares bitlength, and Paillier modulo on performance.
Experiment 1: We know from subsection VII-H 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, it is sufficient to raise k and monitor the execution time. The experiment's results illustrated in Fig. 6, 7, 8, and 9 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 F p prime number p. The shares are primarily generated randomly in 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 64, 128, and 256 bits,   as shown in Figures 6 and 7. The results reveal a minimal effect on performance. Experiment 3: Similarly, we look into the security of the underlying SHE scheme and its impact on performance. Specifically, we target different levels of security by setting the Paillier modulo to 2048, 3072, and 4096 bits. Then we evaluate the differences in performance between the three values. The results specific to the affected phases are illustrated in Figure 8 and Table 9. They show how consequent the impact of changing the security parameter on performance. Although, the results remain reasonable even with 4096-bit security (e.g., under 2.5s for k=25).

IX. CONCLUSION
So far, we have realized a new dynamic, decentralized, and privacy-preserving reputation system. The proposed approach uses blockchain to store and update reputation information in a distributed manner and SMC to ensure feedback privacy. We got a system with better accessibility that preserves reputation information from loss and delivers a complete version of it. Moreover, it is secure in the malicious adversarial model, even with a dishonest majority, which is strong security. Using such techniques, we got a reliable system that is not affected by parties leaving the network.
In future works, we would like to address the issue of privacy alongside other challenges that reputation systems encounter. These challenges include self-promotion, slandering, whitewashing, and oscillation. To this end, we consider exploring advanced cryptographic tools such as data obfuscation, functional encryption, and homomorphic secret-sharing.
Another field of interest for prospective works is decentralized reputation systems for location-sensitive networks such as MANETs and VANETs. In such networks, feedback is relayed by immediate neighbors that are present in the same area as the sender party, and naturally, they know its location. The situation being a clear violation of the sender's privacy, the challenge is to create a protocol that allows parties to provide feedback while remaining anonymous.
Besides, for decentralized systems relying on the blockchain, the issue of blockchain scalability requires special attention. Indeed, blockchain has limitations on the number of processed transactions, and we need to apply additional techniques such as Sharding or Nested Blockchain to overcome the problem and produce a compelling solution.

APPENDIX PRE-PROCESSING PHASE
Protocol 10: Triple : Protocol for random triple generation • Multiply: 1) Each party P i samples a (i) , b (i) ,b (i) $ ← −F. 2) Every unordered pair (P i , P j ) executes the following: a) P i uses NIZKPoK to send P j the encryption Enc pk i (a (i) ). b) P j computes C (ij) =b (j) . Enc pk i (a (i) )−Enc pk i (e (ij) ) for random e (ij) $ ← −F and sends it to P i . c) P i decrypts d (ij) =Dec sk ij (C (ij) ). d) Repeat the last two steps withb (i) to getê (ij) and d (ij) . 3) Each party P i computes c (i) =a (i) . b (i) + j̸ =i (e (ij) + d (ij) ) andĉ (i) similarly.