incentives for cooperation in distributed systems · 2006-09-21 · 35 eigentrust luckily, trust...
TRANSCRIPT
Incentives for Cooperation in Distributed Systems
Beverly Yang
Stanford University
2
Value from consolidating resources across autonomous nodes
Emerging applications
3
Value from consolidating resources across autonomous nodes Web Services
Emerging applications
4
Value from consolidating resources across autonomous nodes Web Services Grid Computing
Emerging applications
5
Value from consolidating resources across autonomous nodes Web Services Grid Computing File-Sharing
Emerging applications
6
a.k.a “peer-to-peer” Consolidating
resources across autonomous nodes
Additional features Massive replication,
scale, loose coupling Robust, self-
organizing, “autonomic” behavior
Emerging applications
7
In research Focus on performance and functionality…
SIGCOMM 2003 (5/33) SOSP 2003 (3/21) SIGMOD 2004 (2/69)
…but overlook autonomy Who says nodes will contribute resources? Who says nodes will cooperate? Who says data/service is authentic?
How useful are techniques without incentives?
8
Incentives
First-class problem How to get nodes to cooperate to achieve
functionality? What is effect on performance?
This talk: Our work on incentives inpeer-to-peer systems
9
Outline
Introduction Context/Example RTR Protocol EigenTrust PPay
10
Example
Alice wants to find a document-translation web service Web
ServicesAlice
11
Example
1. Submit query
?
WebServices
Alice
Receive list ofproviders
12
Example
1. Submit query
Receive list of providers
2. Select providers
WebServices
Alice
13
Example
1. Submit query
Receive list of providers
2. Select providers
3. Invoke services
WebServices
Alice
14
A second look
1. Submit query
Receive list of providers
?Web
ServicesAlice
Opportunistic approach: Participants route • Who says nodes will route? • What if you have competing nodes?
15
A second look
1. Submit query
Receive list of providers
2. Select providers
WebServices
Alice
16
A second look
1. Submit query
Receive list of providers
2. Select providers
3. Invoke services
WebServices
Alice
$$
$$
17
Our contributions
1. Submit query
Receive list of providers
2. Select providers
3. Invoke services
RTR Protocol: Resource discovery incompetitive networks
EigenTrust
PPay: Efficient micropayments
18
Outline
Introduction Context/Example RTR Protocol EigenTrust PPay
19
Example of Non-Cooperation
“Document Translation”?
Provider 1Provider 2
20
RTR Protocol
RTR: “Right To Respond” Queries as commodities Buy and sell RTRs
21
Basic Exchange
2) ReqA B
3) RTR
RTR = {Q, TS, QueryString}Q
A B
Offer = {Reputation(Q), TS, QueryString, Price}
1) OfferA BQ ….
22
Filters Specify query content
Exact service Categories Nothing
Sell query to neighbor only if query matches filter
sdfsdf gasq gsg sabw heaw
23
Pricing
Simple pricing model Understand factors that
influence value Pinpoint parameters that
need to be estimated
∑∈
•+••=
+=
nbN
ffN
AA
AAA
NRTRENRTREIE
fpricepI
RESENE
),()),(|(
)(
)()()(
24
Example of Non-Cooperation
“Document Translation”?
Provider 2Provider 1
25
Functionality
0
0.5
1
1.5
2
2.5
3
3.5
4
Query Score
Cooperative Competitive
No Forward RTR
Query Score
26
Efficiency?
27
Efficiency
0
20
40
60
80
100
120
140
160
# Messages
Cooperative Competitive
No Forward RTR
•Intelligent Routing• Content Clusters
28
Many details
See paper [YKG 03] “Addressing Non-Cooperation in Competitive
Peer-to-Peer Systems” Workshop on Economics in P2P
29
Outline
Introduction Context/Example RTR Protocol EigenTrust PPay
30
Reputation
Not all providers are good
Evaluate using past experience
31
Reputation
Not all providers are good
Evaluate using past experience
Problem: Sparse experience
−−
0
0
0
0
0
0
Node 0
Node 1
Node 2
Node 3
Node 4
Node 5
Node 6
Node 7
Node 8?
?
?
?
?
?
32
Friends of Friends Ask for the opinions
of the people who you trust.
−−
0
0
0
0
0
0
Node 4
Node 1
−−
0
0
0
0
0
0
0
Node 2
Node 6
33
The Math∑ ⋅=j
jkij cccik
'
Ask your friends j
What they think of node k.
And weight each friend’s opinion by how much you
trust him.
TC'ic ic=
.1
.5 0 0 0.2
0 .2 0 .3 0 .5 .1 0 0 0
.1
.3
.2
.3
.1
.1
.2 =
34
Knowing All Peers Ask your friends:
t=CTci. Ask their friends:
t=(CT)2ci. Keep asking until the
cows come home: t=(CT)nci.
−−
0
0
0
0
0
0
−−
0
0
0
0
0
0
−−
0
0
0
0
0
0
−−
0
0
0
0
0
0
35
EigenTrust Luckily, trust vector t, if computed in this
manner, converges to the same thing for every node!
Show how the whole network can cooperate to store and compute t
Show how to handle trust in computation See paper [KSG 02]
“The EigenTrust Algorithm for Reputation Management in P2P Systems”
WWW 2002
36
Outline
Introduction Context/Example RTR Protocol EigenTrust PPay
37
PPay Need money to enable
general resource sharing
Transactions Lightweight No long-term
vendor/buyer relationship
Micropayments
38
$Broker Expenses Handle accounts Distribute and cash coins Security (e.g., double-spend
detection)
Load is O(n) in the number of transactions
Scalability and performance bottleneck
39
Open Account
$U
Cert = {U, AddrU, PKU, Expiry}SKB
Cert
Name, Phone, AddressPayment Account (CC#)PKU
40
Minting Coins
$U
C = {U, sn}SKB
C
“Owner”
PO
PO = {“Buy”, Qty}SKU
41
Assigning Coin
U
AUV = {V, seq1, C}SKU
AUV
V
C $
42
Reassigning Coin
U V X
RUVX = {X, AUV}SKV
RUVX
AUX
AUX = {X, seq2, C}SKU
AUX
RUVX
$
43
Downtime Protocol
U V X
RUVX AUX
AUX = {X, seq2, C}SKB
RUVX
RUVX
UU
$
44
Observations
Peer load higher, broker load lower Leverage resources at peers Broker involvement is linear in coins printed
Peer load scales “perfectly”
45
PPay vs. Electronic Check
1 10 20
x 21
x 8
(BrokerLoad)
46
Additional Details
Security Guarantees Performance Extensions See paper [YG 03]
“PPay: Efficient Micropayments for P2P Systems”
ACM CCS (Communication and Computer Security)
47
Conclusion Incentives: first-order problem
RTR Protocol: Incentive-compatible resource discovery
EigenTrust: Distributed and secure reputation PPay: Efficient micropayment scheme
http://www-db.stanford.edu/peers(Google: stanford peers)
48
Value from consolidating resources across autonomous nodes Web Services Grid Computing File-Sharing Ubiquitous Computing
Emerging applications
49
Flow of Payment
A$$
PurchaseRTR
Q
$$Provide Service
M
N
$$
$$
Resell RTR
•A has service?•Q picks A?•Price of service?
•N buys RTR?•Value of RTR to N?
50
Pricing Model
∑∈
•+••=
+=
nbN
ffN
AA
AAA
NRTRENRTREIE
fpricepI
RESENE
),()),(|(
)(
)()()(
51
Efficient Routing Content filters (if specified) serve as
“routing hints”
52
Communities (“clusters” in topology) will form around content
Content Clusters
53
Characteristics
Vendors AND buyers
Massive resources at nodes
$PPay: Exploit characteristicswhile maintaining security
54
“Good Enough” Security Micropayments are small
Utmost security not required
Must be lightweight
“Good Enough” (def): Fraud is detectable, traceable, and unprofitable
55
Pico Payments
56