1. The Design of A Distributed Rating Scheme for Peer-to-peer Systems Debojyoti Dutta 1, Ashish Goel 2, Ramesh Govindan 1, Hui Zhang 1 1 University of Southern California 2 Stanford University

2. 6/6/2003P2Pecon2 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

3. 6/6/2003P2Pecon3 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]

4. 6/6/2003P2Pecon4 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.

5. 6/6/2003P2Pecon5 A distributed rating scheme To incentivize cooperation in P2P file-sharing systems Main components  Positive rating  Rating verification scheme

6. 6/6/2003P2Pecon6 Positive rating The recognized service done to the community  R i of user i: non-decreasing with the number of successful requests that it has satisfied within some sliding time window.  The higher R i user i has, the better service it gets from the network.

7. 6/6/2003P2Pecon7 Verification-based rating scheme Rating R i User i (i, R’ i ) User j Verify if R’ i is true for i ? Data request

8. 6/6/2003P2Pecon8 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”. lightweight L

9. 6/6/2003P2Pecon9 Assumption Users are distinguished by their IP addresses.  At a given time, one IP address corresponds to an unique user.

10. 6/6/2003P2Pecon10 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.

11. 6/6/2003P2Pecon11 A Chord [stoica2001] supervising overlay 0 32 64 96 128 160 192 224 256 Network user 0 256 Supervising 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.

12. 6/6/2003P2Pecon12 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.

13. 6/6/2003P2Pecon13 Rating verification in SVS user j user i verification request ID(i) Supervising overlay user i’s supervisors Yes/No

14. 6/6/2003P2Pecon14 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. ?

15. 6/6/2003P2Pecon15 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 R i.  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.

16. 6/6/2003P2Pecon16 Randomly sampling without the complete customer list user i’s customer list 0 2 k -1 abcdefgh user i’s customer vector [ 2, 3, 1, 2] hashing

17. 6/6/2003P2Pecon17 P2P users users selfish malicious altruistic colluding non-colluding

18. 6/6/2003P2Pecon18 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.

19. 6/6/2003P2Pecon19 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.

20. 6/6/2003P2Pecon20 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.

21. 6/6/2003P2Pecon21 Backup slides

22. 6/6/2003P2Pecon22 Chord – routing table setup A Chord network with 8 users and 8-bit key space Network user 255 0 64 128 32 192 96 160224 [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

23. 6/6/2003P2Pecon23 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.