Reputation System Design for SingularityNET

1. Introduction

In this document we discuss overall objective, requirements and constraints for design of Reputation system in SingularityNET (SN). We describe its overall design, outline designs of its internal layers such as business logic and storage layers. Finally, we address the plan for implementation and testing of the system.

The objective is to provide design for reputation system to be used in SingularityNET platform accordingly to Singularity Net white paper as well as Proof-of-Reputation concept, so the agents and participants of the platform can rate other agents and participants implicitly or explicitly, being able to review current reputations of the other agents, and reputations of the agents could be used for governance and rewards in the system.

The constraints, requirements and disclaimers for the design are the following.

1. Primary source of reputation will be per-task rating so that value of ratings made by any rating “consumer” agent to any “supplier” agent being rated is bound to amount of AGI tokens transferred from “consumer” agent to “supplier” agent as a “memo” field for each payment for each of successfully completed and accepted task. Normally, this would be done via smart contract associated with particular task performed for “consumer” by “supplier”. That is, use of per-task ratings would be the very basic mechanism for reputation calculation.
2. Also, explicit staking ratings may be used as well, indicating the fact that particular rating “consumer” agent provides its rating value to “supplier” agent out of context of any particular task. In this case, the value of rating will be associated with amount of AGI tokens “frozen” as a “stake”, so neither of the two agents can spend that amount, except rating agent can withdraw the rating back. This could be thought as “staking-based reputation” and can be later used for advanced reputation management, providing benefits for those who provide better reputations and penalties to those who is involved in reputation gaming. This can be also thought as mechanism as explicit way to build Trust Graphs, assuming each rating is expression of “I believe this guy is a good guy and the amount of my belief is that amount of AGI-tokens”. For more details, see materials on “Curation Markets”.
3. No any other implicit or explicit and direct or indirect non-financial ratings (in terms of Proof-of-Reputation concept) based on per-task ratings or mention of agents in text reviews will be used. The reason is that any ratings not backed up by real financial value, like AGI tokens, can be thought not reliable enough while we don’t want to force participants to spend AGI tokens on ratings. Also, we want to avoid having dedicated transactions just for per-task specific ratings, besides conventional payment in AGI-tokens. Any possible use of these in the future may be considered later.
4. Reputation calculation algorithm should be simple enough to get used for “Proof-of-Reputation” consensus (PoR, in terms of Proof-of-Reputation concept) in a blockchain or any other distributed peer-to-peer system based on consensus — this may be valuable if is decided to implement proprietary SingularityNET storage system based on blockchain.
5. It should be possible to implement the system on top of any storage layer, be it conventional relational, graph, object-oriented or other non relational database, including distributed ones such as iPDB. However, we primarily expect the reputation data will be stored in distributed manner with account to distributed consensus algorithm. In particular we want it to be be supportable with Ethereum blockchain.
6. Each of the ratings, backed up with amount of AGI tokens, should be given “overall rating” value in range -1 to 1 inclusively, as real number with 0 as no rating is given, 1 as extremely positive rating and -1 as extremely negative rating. Default value should be 0.5. “Negative ratings” have to be used only for purpose of recall for “positive ratings” given earlier along with transaction of returned payment, so there will be no “reputation overdraft” problem — there will be no way for any agent to provide more negative ratings to any other agent than they have given them earlier.
7. Ratings should be multi-dimensional, with account to specific aspects such as performance, timeliness, accuracy etc., so that each of the ratings may have multiple evaluations of multiple aspects, configured in the system. If such fine-grained ratings are not provided, the default rating value for each of the dimension-specific ratings will be the same as overall rating. Values of domain-specific values and default value will be the same as for overall rating.
8. Reputations calculated on basis of known ratings should vary in range 0 to 5 inclusively, with real number with 5 as the best known reputation and 0 as no any reputation at all. Actually, it may be maintained in range 0 to 1 behind the scene but get mapped to range 0 to 5 for presentation purposes.
9. Ratings could be scoped in respect to specific categories or domains corresponding to particular kinds of tasks, ie. it should be possible to evaluate Beneficial Reputation across agents involved in performing Benefit tasks and separate Non-Beneficial Reputation across agents performing conventional tasks of commercial nature;
10. Defence from inflated ratings and other sorts of ratings gaming should be provided with three approaches: a) hierarchical nature of reputation calculation within reputation algorithm as discussed in Proof-of-Reputation concept, following “Google Juice” idea; b) weighting original ratings with financial values expressed in AGI tokens; c) using dedicated AI techniques for mining fraud and gaming patterns in the ratings dynamics as mentioned in Singularity Net white paper as partially implemented in by Aigents service.
11. Dedicated AI techniques for mining fraud and gaming patterns can not be part of reputation algorithm because of the cost making it impossible to be part of distributed consensus and because straightforward application of these may penalize tight circles of fair partners. This may be potentially designed later as “disciplinary negative ratings” performed by delegated “Reputation Inspection” agent in the following way. Periodically, entire ratings for given period of time are analysed for presence of cheating/gaming. If ones are found, corrective action should be taken.
12. It is anticipated that reputations may be not precise during the first year of the SingularityNET operations.
13. Reputation calculation recursion depth and reputation period should be unlimited.
14. Parameters driving calculation of Reputations such as weights for blending explicit and financial ratings and time rate at which reputations are updated in the system should be kept somewhere in underlying blockchain.
15. Ratings should be saved in underlying blockchain as transactions conveying either regular payments or “stakes” corresponding to AGI tokens and likely in context of specific smart contracts.
16. Currently, known Reputations should be saved in underlying blockchain as account properties and updated periodically given the configured time rate, per “Persistent reputation on-chain” with “Periodic recalculation” design options in Proof-of-Reputation concept.
17. The periodic calculation of reputations to be saved in underlying blockchain happens periodically by dedicated trusted agents, capable to perform function of Reputation Agency, per “Reputation Agencies On-Chain” design option in Proof-of-Reputation concept. It is expected there will be at least 1 agent providing reputation calculation for entire SingularityNET as a beneficial task. Ideally, there should be several Agents doing the same calculation for entire network in competitive and redundant manner, verifying each other so the reputations should not be faked by fault of one of the agents playing role of reputation agency.

2. Overall Design

The entire SingularityNET design and implementation assumes two layers — Agent and Business Logic layer and Crypto (Storage) Layer, with the latter one responsible for financial transfers between the agents as well as storing persistent data required by the system. Because of choosing “Persistent reputation on-chain” with “Periodic recalculation” design options, system-wide reputation data will be periodically updated in single transaction — as kind of “signed state“ in terms of SWIRLDS Hashgraph design). The updated reputation state will be stored in underlying blockchain, using Reputation Storage Layer as part of SN Crypto Layer. Because of “Reputation Agencies On-Chain” design option, we will be computing reputations periodically by one or more dedicated nodes playing role of “Reputation Agency”, with each node running independently in the system periodically and independently. Each act of reputation update in the system by each of the Agents with will be considered Beneficial Task with costs of its operation maintained by community. In case if one of such agents provided inappropriate results declined by Reputation Consensus (discussed further), there should be a way to triage performance of given agent.

The overall design picture with both layers, their API entries and respective data/control flow paths is presented on the following figure.

The computation of reputation is conducted in distributed manner with the following assumptions and design decisions.

• Per-account Reputation — Reputation of every Agent is bound to account of given agent.
• Periodically updated Reputation State — Per-account reputation is performed at reputation update rate specified in crontab format, so the “reputation state” as reputations of every Agent in the system is re-evaluated for specified time periodically, given the input from previous reputation state and all events happening at specified time or later, till the time of latest reputation state.
• Collaborative Reputation Maintenance — Each Agent in “Reputation Agency” can evaluate reputations of all Agents in the system, using the same “Reputation Algorithm”. There could be design option with “sparsely distributed reputation evaluation” so each “Reputation Agent” may calculate reputations only for subset of Agents necessarily, and overall picture would be collected cooperatively — but we are not considering this option now.
• Cross Validation — if more than one Agent plays role of “Reputation Agency” and the reputations are made persistent Crypto (Storage) Layer, it is ensured that reputations calculated by different Agents are matching on per-account basis, so they should be identical. If they are not matching, the dispute resolution should take place accordingly to “Reputation Consensus” algorithm and alert should be sent to system administration/monitoring services of SingularityNET to blame the Agent providing reputations inconsistent with achieved consensus.
• Reputation Consensus — in case if reputation data supplied by different agents mismatch, consensus is achieved by voting performed by agents. The voting by is performed given the latest known reputation of Agents supplying the reputations themselves, using Proof-of-Reputation consensus in fact. The Agent or Agents losing the voting are reported to administration/monitoring services as “suspicious minority”.
• Reputation Inspection — besides the two layers performing conventional day-to-day operations for reputation maintenance and services, there may be additional service performed by dedicated Reputation Inspection Agent (RIA). It’s goal will be study for suspicious and potentially harmful patterns in the history of ratings being made. If they “unfair” ratings are found then involved agents are reported to administration/monitoring services as “suspicious activity”, then possibly “corrective” ratings may be added to the system by RIA and then process of reputation evaluation starts over again — this may be iterative process taking place till “possible fraud” impact gets below given threshold.
• Reputation Parameters — with all of the above, the reputation maintenance is governed by list of parameters to be stored in Crypto (Storage) Layer.

For the initial version, the following parameters would get provided:

• DefaultReputation — default reputation value for newcomer Agents;
• DefaultRating — default rating value for “overall rating” and “per-dimension” ratings;
• Dimensions and their weighting factors for blending — timeliness, accuracy, etc.;
• T&P — Time and period of reputation recalculation/update;
• Tupdate — time required to have reputation consensus achieved;
• Nmin — minimum number of Agents that are required to have reputation state or per-account reputation cross-validated and reputation consensus achieved;
• Nmax — maximum number of Agents that are required to have reputation consensus achieved;
• F, S — Weighting factors for blending per-task and staking ratings when calculating reputation, respectively.
• PR — amount of AGI tokens allocated for curation rewards for the period.

Optionally, to minimize risks of artificially inflated reputations by means of paying for fake tasks, there may be system-wide limits on amount AGI-tokens spent to back up reputations, effectively limiting amount or AGI tokens spent in the system within given limiting period:

• Tlimiting — period of time that limits apply for (day, week, month, year);
• GRmax — maximum amount spent on per-task payments in the period per agent pair
• GAmax — maximum amount spent on per-task payments in the period per agent
• QRmax — maximum amount of staking value in the period per agent pair
• QAmax — maximum amount of staking value in the period per agent
• QQmax — capping amount of staking value per agent pair, regardless of period
• QTmax — capping amount of staking value per agent, regardless of period

3. Reputation Business Logic Design

3.1. Software Architecture

The software architecture in Agent and Business Logic Layer of SN is represented by methods of Agent class and ReputationAgency interface which can be implemented by either a) Agent class or b) specialized ReputationAgent class or c) ReputationAgencyActivity class which can be aggregated by some of the Agents playing the role of Reputation Agency. Possibly, dedicated ReputationInspectionAgent may be added to the suite.

The Agent class has the following methods.

• startup — load reputation cache and parameters on startup.
• pay — accept task id, amount of AGI tokens to pay for particular task, value of overall positive rating for the task plus optional rating values for multiple dimensions. Also can be used with negative values or “return payment” flag in case of cancellation of an earlier task completion acceptance with cash return. As effect, the rating information is saved in the Crypto (Storage) Layer as memo for the transaction in AGI tokens. This method should be used as single entry point method for cross-agent payments so there is always a way to supply rating information along with per-task payment in the same transaction.
• stake — accept agent id and amount of staking value in AGI tokens to put on staking rating for given agent. Negative value of amount or “recall stake” flag can be used to remove rating.
• get_reputations — retrieve all reputations of Agents in the system (by default) or just for subset of Agents (if list of Agents specified) from the cache.

The ReputationAgency interface has the following methods.

• startup — load reputation cache and parameters on startup.
• update_reputations — perform reputation recalculate/update process given reputation algorithm and store new reputations in internal cache and in the Crypto (Storage) Layer.

Method parameters, returns and errors/exceptions to follow.

3.2. Reputation Algorithm

Referring to Proof-of-Reputation concept given constraints above, here are the definitions for the algorithm.

Fijkct — represents “per-task rating”, associated with financial transaction of Gijct AGI tokens reflecting fund transfer from Agent j to Agent i at time t for dimension k and category c — for the task in category c completed by service provider Agent i for service consumer Agent j. Normally, it could be only positive real number value in range [0..1] however there may be negative values in range [-1..0] in case of cancellations of transactions or cash returns under umbrella of smart contracts. So the ratings could be positive or negative however amount of negative ratings between i and j can not exceed amount of positive ratings. 0 will mean no rating is given and will be the default value, which means either no rating is given at all or the lowest possible rating is supplied. In social networks like Facebook, the per-task rating is typically called “like”, in Steemit it is called “vote” (see how the reputation is computed in Steemit). However, in SinglularityNET the value of this rating is weighted with amount of AGI tokens transferred with associated transaction.

Sijkc — represents “staking rating”, associated with ledger record of Qijc AGI tokens as stake made by staking Agent j in respect to Agent i being subject of stake. Similarly to to above, k and c correspond to dimension of rating and category of the tasks for which rating is done.

The following limits may be applied to Gijct and Qijc amounts of AGI tokens in order to lower impact of possible reputation gaming.

• Tlimiting — period of time that limits apply for (day, week, month, year);
• GRmax — maximum amount spent on per-task payments in the period per agent pair
• GAmax — maximum amount spent on per-task payments in the period per agent
• QRmax — maximum amount of staking value in the period per agent pair
• QAmax — maximum amount of staking value in the period per agent
• QQmax — capping amount of staking value per agent pair, regardless of period
• QTmax — capping amount of staking value per agent, regardless of period

The category c corresponds to one of C possible task categories which can be used to classify the tasks. Presumably, it could be either “beneficial task” or “regular” task.

The dimension k corresponds to one of K dimensions such as timeliness, accuracy etc., so there will be more fine-grained rating for each of aspects of service quality. The split values of ratings Fijkct and Sijkc for their “weighting” transactions Gijct and Qijc will be saved in memo field annotated with K components as multi-dimensional rating. If any of K dimensions are omitted, default system-wide value is used.

For blending per-task and staking ratings when calculating reputations, we will use F and S as weightinging factors, respectively.

For building overall dimension-less reputation across multiple dimensions, blending factors Hk will be used for each of configured system-wide dimensions. Classifier of K dimensions with their codes, descriptions and blending factors used for reputation calculation should be stored as parameters of reputation system in Crypto (Storage) Layer.

Pit1 — raw overall reputation growth during the period from t-1 to t1 for agent i computed at time t is based on reputation of all agents j supplying ratings to agent i, with account to normalized reputations Rjtn-1 of these agents at time tn-1, having different reputations blended with respective blending factors, with t value varying in range from tn-1 (inclusively) to tn (exclusively).

Pitn = ( F * Σk(Hk * Σjct(Fijkct * Gijct * Rjtn-1) / Σjct(Gijct * Rjtn-1)) / Σ(Hk) + S * Σk(Hk * Σjc(Sijkc * Qijc * Rjtn-1) / Σjc(Qijc * Rjtn-1)) / Σ(Hk) ) / (F + S)

More fine-grained values for different slices for different categories c of C and dimensions k of K can be computed.

Pictn = ( F * Σk(Hk * Σjt(Fijkct * Gijct * Rjtn-1) / Σj(Gijct * Rjtn-1)) / Σ(Hk) +

S * Σk(Hk * Σj(Sijkc * Qijc * Rjtn-1) / Σj(Qijc * Rjtn-1)) / Σ(Hk) ) / (F + S)

Piktn = ( F * Σjct(Fijkct * Gijct * Rjtn-1) / Σjct(Gijct * Rjtn-1)) +

S * Σjc(Sijkc * Qijc * Rjtn-1) / Σjc(Qijc * Rjtn-1)) ) / (F + S)

Pikctn = ( F * Σjt(Fijkct * Gijct * Rjtn-1) / Σjt(Gijct * Rjtn-1)) +

S * Σj(Sijkc * Qijc * Rjtn-1) / Σj(Qijc * Rjtn-1)) ) / (F + S)

It can be further normalized in the system so that reputation growth over period becomes global relative reputation in agent ecosystem and used to incrementally update previous agent reputation.

dRitn = Pitn / MAXi(Pitn) ) / (tn — tn-1)

Ritn = ( (tn-1 — t0) * Ritn-1 + (tn — tn-1) * Pitn / MAXi(Pitn) ) / (tn — tn-1)

Respectively, fine-grained reputation values for Rictn, Riktn and Rikctn can be computed for different categories and dimensions, respectively.

In case of “Periodic recalculation”, calculation of reputations starts at time t0 and continues incrementally with periods of T&P till the very recent time. In case of “Periodic update”, the update process starts with the latest known tn-1 and is performed incrementally till the latest T&P.

For the beginning of the reputation calculation process for entire system, or for an agent appearing in the system with “blank reputation history” there should be default value Rjt0 = Rdefault.

3.3. Reputation Inspection Agent

The goal of Reputation Inspection Agent is to perform periodic or ad-hoc inspections in order to detect fraudulent reputation loops (“all-round bail” kind of fraud). This could be done with 3rd-party Reputation Agency wrapping social graph analytics services such as Aigents, like it is done for Steemit blockchain, or other kind of service like that.

There are at least two problems to be solved along the way.

• Natural cooperation versus fake cooperation. There could be natural reputation circles and loops/rings indistinguishable from fake ones. For instance, if agent A serves agent B with image recognition service while agent B serves agent A with text summarization then they make mutual payments. In such case, there is no way to figure out if the services are fake or not. So, if we are considering A<=>B as a loop and removing any value of ratings made within this loop, we effectively discourage and members of the community to provide mutual services. To resolve this, the only way to figure out presence of any circle or ring of this kind and then either inspect the involved agents physically, or audit the source code of them or perform “undercover investigation” ordering service to these agents and validating true nature of the services that they perform.
• Temporally spanning cooperations. Either fake or natural reputation loops/rings may be spanning over time so A may be pumping reputation of B in January with promise made by B to pump reputation of A back in July. If trying to do that as part of Reputation Algorithm discussed above, this should be possible to figure out for currently chosen “Periodic recalculation” design option, but if we change to using “Periodic update” one, then we would need to make T&P long enough — months and years which might get too expensive computationally and won’t enable building practical Proof-of-Reputation consensus.

In a nutshell, possibility of fraudulent cooperation can be evaluated using techniques described in Aigents paper so that dense “best friend” relationships occurring with agents having low reputation at the time of such relationships may be thought particularly suspicious. The only change of the existing algorithm would be account for per-task and staking transactions instead of “likes” and “votes” plus the financial value of these transactions would need to get accounted. The extension of this technique could be calculation of “indirect relationships” over “multiple handshakes” using mechanism of “social inference” for discovery of “social cliques”. That is, given input period of time, list of target agents to explore, radius of circle to explore and sensitivity threshold, system should be able to return lists of potentially fraudulent graphs and agents with fraud probabilities attached to them.

Once suspicious agents are found, the fraud may be confirmed with manual agent system and code inspections, automatic or manual “undercover investigations” and other law-enforcement activities.

If suspicious agent is confirmed as fraudulent, the “punishment and reward” functions can be enforced in manual, automated or semi-automated manner, so either agents are excluded from SingluarityNET community, or nature their activity is publicly reported to community so providers of staking reputations can recall they stakes, or there are “corrective downvoting” staking reputations are made to guilty agents on behalf of highly-reputable agents appointed to execute the law enforcement.

The other “financial” way to conduct “punishment and reward” functions would be done in terms of “Curation Markets” principles, so curation rewards to be allocated to Agents that have given effective ratings of other Agents, according to a “curation markets” framework (in which, for example, one Agent can “stake” a certain amount of token on another Agent’s reputation in a certain context, receiving a certain token reward if his rating turns out valuable, and losing (as curation punishment) a small amount of token if it turns out misleading). The combination of machine learning with curation markets will be a critical aspect of the effective functionality of the network.

In simple form, the “automated curation” can be done by “Reputation Curation Algorithm” (and maybe dedicated Reputation Curation Agent) so the relative amount of positive reward or negative punishment Wjtn at time tn for period between tn-1 and tn is computed as sum of all amounts paid by agent j to agent i multiplied by positive or negative growth of the agent i reputation over the period, having these multiplications summed across all agents j.

Wjtn = Σi( (Σct(Gijct + Qijc)) * (Ritn - Ritn-1) )

In order to allocate actual “reward” payments to the agents or withdraw “punishment” funds from their accounts, there is a need to have “punishment and reward” fund allocated. Assuming value of the fund is configured for each period between tn-1 and tn is PR, we can calculate actual Wjtn amount of “punishment and reward” for each of agents at time tn with scaling factor Wtn.

Wtn = PR / Σj(Wjtn)

W’jtn = Wtn * Wjtn

These problems and solutions above can hardly be solved with conventional Reputation Agency agent because require expensive AI and ML learning techniques applied to entire “big data” of network-wide rating history and because it needs actions performed in offline world, interaction audits, code inspections and “undercover investigations” and possibly taking “corrective punishment and reward” actions. So, this will be performed by dedicated agent, to be designed and described later, on the basis of existing functionality being provided by Aigents for mining social structures, like it is done for Steemit and Ethereum blockchains now and extended with capabilities of “undercover operations” and “punishment and reward functions”.

Aigents Service as Reputation Agency

4. Reputation Storage Design

4.1. Software Architecture

Software architecture of the Reputation State and Parameters Storage in SN Crypto (Storage) Layer may be roughly implemented with the following methods:

• startup — overall system initialization at startup;
• put_rating — record rating for one of the tasks completed and paid earlier or revert rating for the task and payment cancelled and returned earlier;
• get_transactions — AGI token transfers and ratings with Reputation tokens;
• get_reputations — get snapshot of system-wide reputations (by default) or reputations of particular set of Agents (if requested so);
• put_reputations — store snapshot of system-wide reputations (by default) or reputations of particular set of Agents (if specified only subset);
• get_paramaters/put_parameters — get and set parameters described above, storing parameters somewhere in blockchain.

For the parameters, the following default values could be provided:

• DefaultReputation = 0.1;
• DefaultRating = 0.5;
• Dimensions with blending — timeliness 0.5, accuracy 0.5;
• T&P = daily, midnight GTM;
• Tupdate = 12 hours;
• Nmin = 2;
• Nmax = 3;
• ORmax = 10%;
• OAmax = 0, so no absolute limit applies by default;
• DRmax = 10%;
• DAmax = 0, so no absolute limit applies by default.
• Tupdate — time required to have reputation consensus achieved;
• F = 0.5;
• S = 0.5;
• PR = 0, which means curation punishments and rewards do not apply;
• Tlimiting — none;
• GRmax — none;
• GAmax — none;
• QRmax — none;
• QAmax — none;
• QQmax — none;
• QTmax — none.

4.2. Reputation Consensus Algorithm

This should assure all agents supplying reputations are supplying identical reputation data for the same agents for given time so the data can be cross-validated. Since we assume that every agent playing role of Reputation Agency must be computing reputations for every agent in the system, it could be as simple as the following.

1. We need every submitted state of reputation data should provide reputations for all known agents.
2. Each subsequent state after the first one should be identical to the previous one.
3. If there is a state non equal to previous, the set of subsequent states is marked as being disputed and warning to administration/monitoring services is sent.
4. Once there is Nmin identical states received, the state is marked as valid and no more states are accepted.
5. Once there is Nmax non-identical states received and there is at least Nmin identical states, the state which is supported by most of submissions is marked as valid, no more states are accepted and and warning to administration/monitoring services is sent blaming minority of on-identical state submitters.
6. If neither #4 nor #5 happens within time period Tupdate starting next checkpoint per T&P, warning to administration/monitoring services is sent.

5. Road Ahead

5.1 Ways to go

The design above may be implemented as part of SingularityNET Agent layer with new dedicated Reputation Agency Agents running on top of Ethereum-based blockchain Crypto (Storage) Layer implementation. Or, separate independent Reputation Agency can be implemented off-chain or on any other blockchain, accordingly to possible options.

The Reputation Inspection Agency can be implemented either using existing Aigents service as SingularityNET Agent Python wrapper around standalone Aigents server in Java) or porting the latter to SingularityNET Python Agent.

Later, it might get possible to re-implement the design above with change Crypto (Storage) Layer to use another blockchain such as EOS (given EOS roadmap) or other blockchian or hashgraph or custom proprietary blockchain solution with Proof-of-Reputation consensus built-in.

5.2. Simulating Ecosystems

It is desired to have simulation model making experimental simulation of rating exchange and reputation dynamics in artificial network, targeting to figure out the following.

1. Whether Proof-of-Reputation is more tolerant to network takeover, compared to Proof-of-Work and Proof-of-Stake.
2. Whether per-task or staking kind of ratings are more valuable for building safer reputation system.
3. What kinds of reputation gaming attacks can be expected and what could be the ways of resistance to them.
4. What is the best combination of the reputation system parameters.