Written by Philipp on 2019-02-07

Distributed Trust – Reputation Systems in the Blockchain

Security . Tech

Distributed Reputation Systems in the Blockchain

Almost every project that serves the interaction of people uses a concept for evaluating the reputation of its participants. If the implementation is still simple and clear at the beginning of a project, often even a bit naive, the demands grow over the further life cycle of a system.

Contents

1. Desired Properties of a Reputation System
2. Possible Implementations
3. References

A reputation system is a system that maps a relationship between two entities. This relationship has a different name depending on the system; in most cases it is called a “rating”.

This article provides practical guidance for implementing distributed reputation systems for blockchain-based projects. Most of these recommendations apply to both distributed and centralized systems.

Desired Properties of a Reputation System

Let’s look at the desired properties of a reputation system:

High User Participation

A system lives from the high participation of its users. User participation is measured by different metrics:

• How high is the share of users who have been rated? (Rated Coverage)
• How many users have actually submitted a rating? (Rater Participation)
• How high is the share of actually rated events? (Event Coverage)
• How high was the quality of the individual ratings? (Rating Quality Coverage)

What counts as strong user participation differs depending on the use case.
Some systems need participation as close to 100% as possible, while other systems already work with lower user participation.

Resilience Against Manipulation

As soon as a system is used more widely and has proven its usefulness, it also becomes a worthwhile target for various attacks and manipulation attempts, with the intent of damaging the reputation of individual participants.

Possible attacks are:

• Self-promoting attack

  Illegitimately obtaining good ratings. This can happen either by creating and operating artificial accounts (sock puppets) – then it is also called a Sybil attack – or by influencing other accounts, e.g. by buying good ratings for money.

• Slandering attack

  Similar to a self-promoting attack. However, the goal here is to give a participant an unjustified, bad rating. The means to achieve this are similar.

• Whitewashing attack

  Is a method to get rid of bad ratings. The simplest way to do this is to create a new identity that has no connection to the previous one. Sometimes ratings also lose their relevance (reputation decay), then the respective owner of an identity simply has to wait until the bad rating has disappeared from the system.

• Oscillation attack

  Also works on the basis of reputation decay. The goal here is to build up a good reputation for a while through positive actions, only to use it later for a while for multiple violations (e.g. fraud).

• Orchestrated

  Combinations of the above and other attacks can in principle reach arbitrary complexity. For distributed systems that know no central authority that can recognize individual attackers and possibly exclude them from the system, it is particularly important to keep the influence of such manipulations as low as possible.
  An important tool for this can be to store only the raw rating data in the blockchain and perform the evaluation locally. This allows more complex calculations but also a faster reaction to discovered attack patterns.

Distinguishability Between New Participants and Participants with Bad Reputation

A newly created identity should be clearly distinguishable from an identity with many bad ratings. In a centralized system, this is very easy to implement. In a distributed system with pseudonyms or even complete anonymity – properties that many blockchains share – this is not so easy.

If creating a new identity is easy, anyone with a bad reputation can simply start over. This makes it impossible to distinguish users with a bad reputation from complete newcomers. One way to achieve this anyway is to require additional verification (e.g. by using identity procedures).

Should the circumstances not allow this, it makes sense for new participants to build up a reputation very slowly and over a longer period, without this having a major influence on their actual rating.
Often it is also central authorities that can perform this verification (ePerso, PostIdent), which can weaken the advantages of a decentralized reputation system.

Access Time to Results

A reputation system is only truly useful if the results are available promptly and up to date. An accepted timeframe here is rather a maximum of seconds than minutes. However, the architecture of blockchain-based systems entails a certain latency until data is reliably stored and distributed. To achieve acceptable response times, a cache is usually used, which can then react faster and be queried more easily. A cache means that a single system becomes the single point of trust. This again contradicts the desired behavior of a decentralized system.

Possible Implementations

Below we would like to present a few implementations that can be used in a blockchain-based reputation system:

Multidimensionality

A reputation often contains multiple dimensions. A good carpenter will be rated on different properties than a taxi driver. An apartment may be suitable for a party-goer, but unsuitable for a young family with children.

In addition to these obviously different dimensions, further, finer gradations are often necessary. A restaurant may have good ratings on average, but may behave dismissively towards families with children.

A well-defined reputation system should be able to consider and map these different factors.

To keep user participation high – and thus the significance of the reputation system – the number of offered dimensions should be appropriate for the respective use case. The rating of an Airbnb accommodation includes numerous dimensions, while the rating of an Uber driver includes only a single value. Below are a few examples of use cases for and against multidimensionality:

Ride sharing: In this case, the rating refers to short interactions with little economic value. A complex multidimensional rating system would probably harm participation. However, to ensure interoperability, it would be necessary to distinguish e.g. between driving style (a specific dimension) and friendliness (a generic dimension).

Scientific papers: The effort to assess a scientific paper is high. Therefore, no decline in participation is to be expected through the use of a multidimensional rating system. Examples of dimensions here would be reproducibility, statistical quality, clarity, scientific contribution. It is probably sensible to shape the dimensions according to the scientific discipline.

Clear Rating Scale

For a rating system to offer added value to a user, the measurement range of a rating should match the problem case.

Contrary to initial assumptions, the significance decreases the more one tries to map a rating as exactly as possible to the use case. Exact ratings are often more difficult to define and measure. This leads to a wider range of variations and ultimately to more noise, which distracts from the actual weighting.

In the past, between five or ten levels were used. Studies have shown that this leads to bipolar voting. This means that a rating is either particularly good or particularly bad, or, in the case of an unclear statement (cleanliness 4/10 stars), again leads to a wider range of variations.

One consequence can be to define four different states; this is currently also successfully implemented on many online platforms. This model provides that one can either vote good or bad, abstain, or report a contribution as inappropriate. Thus, the model very clearly defines the meaning of the respective states. Below again our two examples, which illustrate the different effects of a rating scale:

Ride sharing: The system can be mapped very easily with 4 states. The reduced complexity per dimension compared to a five-level rating scale also makes it easier to map an additional generic dimension without noticeably increasing the effort for the user.

Scientific papers: The classic scale in the scientific field includes four levels (Strong Accept, Weak Accept, Weak Reject, Strong Reject). By increasing the dimensionality as suggested above, the significance of the rating can even be increased while keeping a four-part scale.

Privacy and Data Protection

A rating should be implemented as transparently as possible, and this usually also under the protection of the identity of the respective parties. The ratings themselves can also be personal data, because the existence of rating data allows conclusions about the preferences and activities of the rater.

To make manipulation more difficult, the possibility of submitting a rating is often tied to the existence of an actual transaction. To ensure this while preserving the privacy of all parties involved, it is necessary to use zero-knowledge proofs or to introduce a system analogous to so-called mixers for privacy-oriented cryptocurrencies.

Ride sharing: Ratings from ride sharing services are particularly critical because they allow conclusions about the movement profile. A distributed system whose data is generally accessible should therefore use the aforementioned measures.

Scientific papers: While the review process for scientific papers is currently theoretically anonymous, there are of course external channels through which this information is distributed. Mapping these networks in the system can only benefit scientific hygiene.

Interpretability of Results

A property of a decentralized system is that the user can choose which rating data they want to receive and which data they trust. Unlike a centralized system, this is left to the user.

Different data can be combined to the desired result through personal weightings. Identical base data can thus be interpreted appropriately for each user. This is best implemented by a function that takes the parameters supplied by the user and the base values from the blockchain. Thus, every individual user gets a specific result, but the calculation itself remains reproducible.

Ride sharing: Here the focus must clearly be on mobile availability of the results. Thus, it is not practical for every end device to use the complete blockchain for evaluation. The interpretation will therefore rely on trustworthy caches in this case, which however disclose their algorithms.

Scientific papers: In the case of scientific papers, interpretability is very important. The subjective weighting can depend both on the rater and on various time factors.

References

1. Naercio Magaia, Paulo Pereira, Miguel Correia, “REPSYS: A Robust and Distributed Reputation System for Delay-Tolerant Networks”, http://www.gsd.inesc-id.pt/mpc/pubs/mswim33s-magaiaA.pdf
2. Le Quoc Hung, Karl Aberer, “A Probabilistic Framework for Decentralized, Management of Trust and Quality”, https://www.researchgate.net/publication/37449860/
3. Nan Hu, Paul A. Pavlou, Jennifer Zhang, “Can Online Word-of-Mouth Communication Reveal True Product Quality?”, https://pdfs.semanticscholar.org/3d8b/b2f10378324ca105c2b12e24de18b01c1f69.pdf
4. Tom Slee, “Some Obvious Things About Internet Reputation Systems”, http://tomslee.net/2013/09/some-obvious-things-about-internet-reputation-systems.html
5. “Zero-knowledge proofs”, https://en.wikipedia.org/wiki/Zero-knowledge_proof
6. Stefan Schiffner, Andreas Pashalidis, Elmar Tischhauser, “On the Limits of Privacy in Reputation Systems”, https://www.esat.kuleuven.be/cosic/publications/article-2052.pdf

Conclusion

Some challenges are very specific to systems that want or have to work without a central authority.

For distributed systems without a central authority that watches over the integrity of the system and that usually offer only limited possibilities to roll out changes to the basic paradigms of the system, it is particularly important to thoroughly think through these concepts from the start and to clearly define the design requirements.

This article was originally published in the Entwicklermagazin Vol.18: Blockchain (S&S Media Verlag) and reprinted on the INNOQ blog. Co-author: Christoph Witzany.