CS269I：Incentives in Computer Science 学习笔记： Lecture 5 Incentives in Peer-to-Peer Networks（P2P中的激励政策）

Lecture 5 Incentives in Peer-to-Peer Networks（P2P中的激励政策）

1 P2P Networks : Some History

起源：1999 Napster：作为一个“媒人”，将需要某个文件和已有某个文件的人配对，之后在完成配对的用户之间直接进行文件传输

​ 2000年，由于这种行为导致了大量侵权，，Napster受到了大量起诉，在2001年关闭。

​ 政府的干预行为表明了这种系统的弱点——centralized（中心化），因此，不久之后，第二代系统Gnutella诞生了，它是完全decentralized（去中心化）的，让两个使用者可以不通过服务器，完全直接地接触，传递文件。（P2P：Peer-to-Peer）

问题：这要求Gnutella的用户有动力去传递自己所有的文件。

定义：free-rider（白嫖）：只获得、不付出的行为

研究：接近2/3的用户在白嫖，1%的用户贡献了37%的上传文件。

​ 这种结构并不稳定——一直在上传的人很快就厌倦了别人的“白嫖”。在2005年，“白嫖”的人数达到了85%，后来Gnutella很快就销声匿迹了。

2 The Prisoner’s Dilemma（囚徒困境）

讨论：接下来我们会引入经济学中“囚徒困境”的概念，并迁移到P2P上来

例如，我们写出博弈的payoff-matrix（支付矩阵）：

（A的收益，B的收益）	B：上传文件	B：不上传
A：上传文件	2，2	-1，3
A：不上传	3，-1	0，0

dominant-strategy（占优策略）：不论他人如何选择，都对自己更有利的策略

​ 显然，不论对方怎么选择，不上传文件的收益都更高，因此不上传是个占优策略

​ 但是，如果两个人都选择不上传，则最终的收益是（0，0），但是事实上都上传得到的是（2，2），是一个Pareto改进，然而双方都并没有动力去这么做，这就是著名的囚徒困境。

3 The Repeated Prisoner’s Dilemma（重复博弈囚徒困境）

针对Gnutella的“白嫖”研究告诉我们，囚徒困境是确实存在的，而且很显著。不过，现实中很多状况也并非如此，例如公司间的“战争”一般并不会造成囚徒困境，接下来我们将会使用一个重复博弈的模型来解释它

3.1 Model of Repeated Play

解释：在现实中，有时候人们会因为看到长期回报而放弃短期利益。

模型：A，B重复n次博弈，总回报为n次博弈的总收益，第i轮的选择可以取决于前(i-1)轮中的回报/状态

分析：不论之前如何做出选择，在最后一次必然选择不合作（上传），那么倒数第二次知道下次要选择不合作，这次自然也选择不合作（长期利益固定）；以此类推，A和B的选择仍然是每次都背叛。

改进：A和B的博弈轮数更改为随机的——在每一轮中，有p的概率这个博弈会结束。

3.2 The Emergence of Cooperation

Grim-Trigger Strategy（冷酷-触发战略）：如果对方没有背叛（不合作）过，则合作；而一旦对方背叛一次，之后永远不再合作

​ 如果给定A采用冷酷战略，则B若背叛一次，收益为3，此后一直为0；而不背叛，则收益为2，此后至少为2(1-p)，因此2+2(1-p)≥3可解得p≤1/2。

​ 因此，如果博弈每一轮继续下去的概率大于1/2，则B有动力不背叛（相当于，未来的可能收益越大，B不背叛的可能性就越强）

Tit-for-tat Strategy(以牙还牙)：在第一轮合作，之后每一轮重复上一轮对方的选择

分析：同理，当给定A使用tft战略的时候，p若小于等于1/2，则B有动力一直合作下去

​ 这个模型很好地模拟了人生（报复和回报都是存在的，但是很快就被遗忘）

3.3 The Axelrod Tournaments

讨论：1980年时，Axelrod做了一个实验，来模拟不同的博弈策略在竞争中得到的收益。令人震惊的是，Tft在这个实验中连赢两局——尽管它被很多策略针对，但它的综合表现真的非常不错。

3.4 Lessons Learned（经验教训）

囚徒困境蕴含着个人利益与集体利益的冲突。然而，在更加长期的竞争中，Tft表现得十分高明。

4 Bit Torrent（BT种子）

4.1 The Protocol（协议）

背景：比特流协议是P2P传输协议的典范。2013年时，比特流占用了高达80%的P2P流量

内容：解决传输大文件时的速度问题：

​ Swarm（群组）：一群想要同一个文件的人

​ Tracker（跟踪器）：跟踪目前的活跃用户群，使用Distribute Hash Table（DHT，分布式哈希表）

​ 当用户加入一个群组时，会与Tracker联系，获得群中用户的一个随机子集，然后向表中的每个用户挨个请求数据。

​ 大文件通常被分成若干个碎片传输。

​ 由于文件的碎片化传输（通常要数十个小时），用户有机会监控其他人的行为。

4.2 Default Settings

实现：

1. 用户每15-30min向群组跟踪器重新请求一个群组内的用户列表，并入已有的列表。用户获得的组内所有用户称为其peer（同伴）。

2. 同伴会定期交换拥有文档区域的信息。

3. 用户会尝试同时从所有**relevant（关联）**的同伴那里下载文件。用户a和b关联，若A，B拥有至少一个共同的文件碎片。

4. 对于参数s，一个用户同时向s个同伴发送文件，每个发送占用1/s的上载通道容量，s一般取值为4.

5. 这s个同伴的选择基于一个TFT策略的变种——对于这个用户，他选择前（s-1）个他在上个时间周期（例如，15s）内从那里下载数据最多的用户来发送文件（作为回报），最后一个则会随机地发送给同伴中的某个人。这s个被传输文件的用户称为对该用户unblocking（无阻塞），其余人称为被该用户阻塞。

6. 当用户在给同伴传文件的时候，他会传他认为中最稀有的文件。（通常有一个算法来计算）

附加：

​ 如果一个人是新来的，那么他不是任何人的关联同伴。因此，他只有机会通过随机发送来获取文件。这个行为称为“optimistic unchocking”（积极无阻塞）。只要他被幸运砸中几次，他就可以在群组中发光放热了。

4.3 BitThief & BitTyrant

讨论：这个规则虽然激励了人们上传文件的行为，但也并非完全不防策略，下面是两个例子：

1. BitThief

   这个程序通过向跟踪器非常频繁地（远超正常速度）请求用户名单，来在不进行任何上传的情况下通过积极无阻塞下载到所有文件。下载速度会比正常用户慢5倍，但并非完全不能用。

2. BitTyrant

   这个程序试图加快下载速度。它对群组中的每个用户i得到两个估计值：d_i和u_i，其中d_i表示如果i没有阻塞自己，则自己可以从i获取的数据量；而u_ij表示自己需要向i传输的能够使其开放阻塞的数据量。

   这两个数据的估算非常容易——只要i向自己传递过文件（例如，通过积极无阻塞的方式），那么，自己就可以算出d_i；如果不断向i增加传送数据量直到其开放阻塞为止，那么最后一轮的向i传送的数据量就是u_i的估计值。

   产生估计后，用户使用贪心算法选择d_ij/u_ij，即性价比最高的用户，仅向他们传送文件，来加快获取文件的速度。