The Design of A Distributed Rating Scheme for Peer-to-peer Systems

Debojyoti Dutta1, Ashish Goel2, Ramesh Govindan1, Hui

Zhang1

1University of Southern California

2Stanford University

6/6/2003 P2Pecon 2

Outline

• Research motivations

• Basic design issues in P2P rating schemes

• A distributed rating scheme to incentivize cooperation in P2P file-sharing systems

• Dealing with collusion and malice

• Conclusion & future work

6/6/2003 P2Pecon 3

Research motivations

• Object: P2P file-sharing systems

Open social communities.

An explicit reputation layer was ignored in the original design.

• Goal: Build reputation in such systems

Incentive for user participation

free-riding phenomenon [Adar et al. 2000][Saroiu et al.

2001]

Isolation of malicious users

distribution of inauthentic files

propagation of virus or worms [VBS.Gnutella][Fizzer.Kazza]

6/6/2003 P2Pecon 4

P2P rating: basic design issues

• “Efficient” rating

low cost to run and maintain this reputation system.

• “Distributed” rating

following P2P design philosophy.

• “Collusion-proof” rating

Effectiveness.

6/6/2003 P2Pecon 5

A distributed rating scheme

• To incentivize cooperation in P2P file-sharing systems

• Main components

Positive rating

Rating verification scheme

6/6/2003 P2Pecon 6

Positive rating

• The recognized service done to the community

Ri of user i: non-decreasing with the number of

successful requests that it has satisfied within some sliding time window.

The higher Ri user i has, the better service it gets

from the network.

6/6/2003 P2Pecon 7

Verification-based rating scheme

Rating Ri

User i

(i, R’i)

User j

Verify if R’i is true for i

?

Data request

6/6/2003 P2Pecon 8

Two verification schemes

• Structured verification scheme (SVS)

Each user has a set of designated supervisors which keep its up-to-date reputation information.

The supervisors are responsible for the verification.

• Unstructured verification scheme (UVS)

A user j queries some of user i’s claimed customers for the verification, and believes i when the majority of the probed users reply with a “yes”.

lightweightL

6/6/2003 P2Pecon 9

Assumption

• Users are distinguished by their IP addresses.

At a given time, one IP address corresponds to an unique user.

6/6/2003 P2Pecon 10

SVS – the supervising topology

• In the supervisory directed graph

Any user is random to its supervisors.

No small supervising loop exists.

There is a fast reactive approach for any user j to deliver a message to any other user i’s supervisors, and the path never includes i.

6/6/2003 P2Pecon 11

A Chord[stoica2001] supervising overlay

0

32

64

96

128

160

192

224

256

Network user0

256Supervising Pointer

A Chord network with 8 users and 8-bit key space

All routing operations go clockwise

Each user has a O(logN)-entry routing table and a O(logN)-successor list.

6/6/2003 P2Pecon 12

SVS – the supervising topology

• In the supervisory directed graph

Any user is random to its supervisors.

No small supervising loop exists.

There is a fast reactive approach for any user j to deliver a message to any other user i’s supervisors, and the path never includes i.

6/6/2003 P2Pecon 13

Rating verification in SVS

user j user i

verification request

ID(i)

Supervising overlay

user i’s supervisors

Yes/No

Yes/No

6/6/2003 P2Pecon 14

Structured verification scheme

• “Distributed” rating

• “Collusion-proof” rating

• “Efficient” rating

Extra cost to maintain a supervisory overlay when the underlying network is not DHT-based.

Repetitive actions when there are multiple supervisors.

?

6/6/2003 P2Pecon 15

Unstructured verification scheme

1. When user j decides to verify user i’s rating, it gets a portion of i’s customer list, and asks the users on the list if i did the claimed service to them.

2. When the majority of the probed users reply with a “yes”, j is convinced that R’i is Ri.

The customer samples should be random on the full customer list of node i.

Disclosure of full customer list could raise privacy concern, and incur high communication cost.

6/6/2003 P2Pecon 16

Randomly sampling without the complete customer list

user i’s customer list

0 2k-1

a b c d e f g h

user i’s customer vector

[ 2, 3, 1, 2]

hashing

6/6/2003 P2Pecon 17

P2P users

users

selfish maliciousaltruistic

colludingnon-colluding

6/6/2003 P2Pecon 18

Colluding selfish users• Possible solution 1: discrete rating

Grade : if a user has served no more than 10 users.

Grade : if a user has served between 10 and 100 users.

Grade : if a user has served more than 1000 users.

• Possible solution 2: rating as virtual currency

A user has to pay (reduce its rating) for the service it claims to have received.

SVS: asks the requestor’s supervisors for a payment.

LUVS: future work.

6/6/2003 P2Pecon 19

Colluding malicious users

• One possible strategy

1. A user i quickly earns a high rating by faking transactions with other colluding users.

2. User i then does bad things until earns bad-enough reputation.

3. User i quits the network to clear its history,

4. User i rejoins the network and repeats the above actions.

6/6/2003 P2Pecon 20

Conclusion & future work

• A simple distributed rating scheme to incentivize cooperation in P2P file-sharing systems.

Two distinct verification schemes

• Refine LUVS scheme to handle colluding selfish users.

• Refine our rating scheme to be collusion-proof.

6/6/2003 P2Pecon 21

Backup slides

6/6/2003 P2Pecon 22

Chord – routing table setup

A Chord network with 8 users and 8-bit key space

Network user

2550 64 12832 19296 160 224

[1,2)Range 1

[2,4)Range 2

[4,8)Range 3

[8,16)Range 4

[16,32)Range 5

[32,64)Range 6

[64,128)Range 7

[128,256)Range 8

Pointer

6/6/2003 P2Pecon 23

P2P users

• Selfish vs. malicious

Selfish users: maximize the number of successful requests with good quality.

Malicious users: subvert the system.

• Non-colluding vs. colluding

Non-colluding users: work individually.

colluding users: organize into a clique with some common interests.