写于 2021-06-10，因要换电脑，爬丢失，因此上传至Mirror。

在之前“几个好玩的激励设计”文章里，我笼统的介绍了swarm大概有哪些激励设计。今天继续就来说明下这个在Swarm中最重要的激励措施之一“带宽激励”。

Bandwidth incentives（带宽激励）

带宽激励的设计，在我的角度来说就是一把双刃剑，具体原因后面会慢慢叙说。

带宽激励-本质上是建立一种信任关系用以带宽互换。它想做的就是让节点可以像中间人一样帮助别的节点去接收或者去发送信息给另外的节点。最简单理解是有那么三个节点A，B，C。无论A要发给C东西还是C反馈给A，都有大概率有可能经过B的转发。打个比方：比如我写文章时已经有近30万个测试节点的话，A节点怎么可能和另外的每个节点产生直接联系，所以需要中间者，可以只有一个B或者很多B1，B2，B（n+1）。

因此，Swarm就是靠这个模型来upload（上传）和download（下载）的。转换下就很容易理解了，A如果要下载东西，发送了请求，B或B（n+1）没有，那么B或B（n+1）转发，巧了，C正好有，这时候C会按原路径把区块发还回去。上传同理。下图为下载示例图：

带宽如何激励呢？其实原理很简单，我的理解就是“赊账”

日常故事理解带宽激励的基本原理

精神小伙老王搬家到了一个新的地方，老王因为弄堂口有个小卖部很近很方便，就去那买东西，爷叔人很nice，小卖部明码标价也十分清楚，老王买了一堆东西，他知道自己买了一共100块钱的东西，结账的时候，老板也是只收了你老王100块钱，往后老王去的次数多了，和老板熟络了，于是有了赊账的特权，老板每次都会帮老王记账，老王自己也会给自己记账，赊账的信用会跟着双方感情越来越好而上升，从赊账一天到赊账两天、三天、一礼拜、1个月，一个季度，甚至到半年、一年。

但在这个赊账过程中，是有个上限的，比如老王一次性在把半个小卖部明面上的东西全买了加上之前赊账的（比如5万元），那老板肯定要老王马上还钱。老王不能使用现金，所以只能还支票，如果老王还不起，老板就损失了，如果老王立马还了，则可以继续赊账之旅。

在此我们先了解下“支票”。在整个运作中，你的settlement只能付支票，支票就和现实中一样，你得先存一笔钱进去，拿到支票簿，到上限了要还钱了，就得开支票去还钱，对方会拿着你的支票，选择去或者不去智能合约那里把钱换出来。

从故事中的角色转换下。赊账就是信用分

节点刚进入的时候，就是记分，记录你使用or提供了多少的带宽。

然后你的带宽信用阈值会随着时间成正比上升，大家交互的时候，谁到了上限就要发settlement。

叙述到此处，来讲下为何是把双刃剑，要再次声明的是整个环节是一个信任关系。（记住这点）

有种可能：节点A和节点B因为这个互信机制，大家一直是在对等的阈值内，都没超标，所以双方的信用一直很好，以至于可以赊账的时间和额度也在逐步增加，但其实在同时，双方可能亏钱的概率也是在正比上升的。万一有一天节点A突然要下载个《方舟：生存进化》，信用阈值到了上限了，可是并没有发送settlement，节点B会因为在这个机制下，只能选择强制自动断开，而损失的钱和带宽，是没可能再要回来了。当然节点A也会付出代价的，可是蒙受最大损失的是那个提供节点带宽的节点B。

另一个的版本的故事则是：节点A发送了settlement，也付给了节点B支票，可是当节点B去智能合约兑现支票时，却提取失败，因为节点A存在智能合约的钱不够支付。

最后，我并不否认这个激励机制的可能性，我所提供的是机制下可能存在的风险，对于这个机制可以参考现有的真实世界的信用制度，比如信用卡，比如贷款，没有巨大的体量并不会对系统造成毁灭打击。

每个优秀的系统都有自己的独特设计，Swarm带宽激励虽然看上去并不完美，但依然是解决问题的可行路径之一。我们作为矿工或者项目研究者需要对这一点有深刻的认知。

分割线下方不发公号 但也保留在石墨文档里 当做团队内部讨论

（此处括号内发公号时候删除，纯发泄，我就是不看好这个激励，什么鬼简直，银行面对的风险直接分摊架在在每个用户身上，现实世界有警察有法律约束每个人行为，这系统有什么？惩罚？巨大波动会导致所有节点奔溃，恶意内容需求者突然要求巨大地图数据，无限发支票，并不是每个节点都能及时取支票，内容下载完了，最后大家发现支票是空头支票。呵呵呵，要崩一起崩了）