干货 | 代币工程学系列,Part3:比特币分析、海洋协议设计

Ajian   |     |   772 次阅读


代币工程学系列:

观点 | 代币工程学系列,Part-1
干货 | 代币工程学系列,Part-2


1. 介绍

在前几篇文章中,我们谈到为什么建立代币生态系统时需要引入激励机制;以及代币工程实践的一些想法。我们可以使用这些工具分析现有的代币生态系统,并进行全新的设计。本文会以上述的方法进行两部分案例研究,(1)比特币分析;(2)设计海洋协议(Ocean Protocol)。让我们开始吧!

2. 案例研究:比特币分析

我们已经讨论过,优化问题的最佳策略可以用于代币设计,所以让我们用最优化问题的视角审视比特币。值得注意的是,我们会将重点放在比特币的目标函数上。

比特币的目标函数是:最大限度地提高比特币网络安全性。比特币将“安全性”定义为算力(hash rate),这使得想要回滚交易的成本变得非常高昂。比特币的区块激励函数维系着这个目标——对提升网络算力的人提供区块激励代币(BTC)。

如下图,我们写下目标函数(区块奖励函数)。等式左边是参与者 i 预期可以在一个区块间隔内得到代币奖励数量(R);等式右边是参与者 i 贡献的算力(hash rate)和每个区块的代币分配数 T。左边与右边成比例(α)。目前 T 的值是每十分钟 12.5 BTC,每四年减半一次。

交易方差对效率的影响

请注意,E() 指的激励是激励的 期望值;这表示每一位参与者不一定能在出块区间内获得区块激励,在比特币中也是一样,激励是起伏不定的:每次 只有一位 参与者能从一个出块区间获得激励。但是因为参与者获得激励的机会与他们贡献的哈希率相关,所以他们对激励的期望值也与贡献哈希率相关。兰花团队(Orchid team)将此称为概率性小额付款。

为什么在每个区块间,比特币对于每一位参与者激励要设计有如此剧烈的波动(高方差),而不是直接激励每一位参与者(低方差)?这么做是有一定好处的:

  • 不需要追踪每一位参与者的贡献度,减少计算和带宽需求。
  • 不需要在每一次区块间发送比特币给每一位参与者,减少交易数和带宽需求。连锁效率!
  • 在上面两者的前提下,系统可以更为简单,也因此减少被攻击的机会。简而言之,越简单,越安全。

以上好处非常显著,但也带来了高方差的严重问题:要真正有机会赢取奖励,你需要巨大的哈希算力,然而这是个赢家通吃结局。不过这种高方差的问题,可以被大型矿池所缓解,矿池可以直接降低方差。很棒是不!因为这样一来,比特币网络不需要亲自出马,问题就已经被解决了。一如往常,我们又再次被中本聪所折服 :)

比特币的激励机制成功吗?

比特币在最大化巩固网络安全性方面,究竟做的有多好呢?答案是:好的不可思议!比特币的激励已经刺激人们投入了数亿美元设计特制的 ASIC 矿机和建造矿场上;还有一部分人成立了由成百上千矿工组成的矿池。目前比特币网络的哈希算力已经超过超级计算机的总和,消耗的电力也超过了世界上大部分的小国家,并有望在 2019 年 7 月之前超过美国的消耗量。这全都是为了获得比特币区块代币奖励!(当然不只有这个好处)

-它从一开始单纯的区块奖励,衍生出各式各样的复杂性,包含矿场 [ 图片来源:维基共享 ]-

除了 ASIC 矿场和矿池,我们也看到了围绕着比特币所产生的整个生态系。软件钱包、硬件钱包、核心开发者、app 开发者、无数的 Reddit 帖子、会议......等等。比特币持有者想要将他们的代币向全世界传播,是驱动这一切的因素。

4. 案例研究:海洋协议设计

(编者注:我也很好奇为什么作者先写第 4 节再写第 3 节。第 3 节为结论。)

-海洋协议-

4.1 介绍

当我们开始在 2017 年 5 月投身为海洋协议(Ocean Protocol)设计代币的时候,我们陷入泥淖。我们没有制定目标(目标函数和条件约束),相反的,我们只简单地看了看像去中心化市场那样即插即用的模式。但后来我们扪心自问:这么做,会为数据共享带来帮助吗?不,并不会。这个协议有需要拥有自己的代币吗?不,不需要。种种问题,我们都这么问过自己。

因此,我们决定回退一步;写出合适的目标函数及条件约束,作为当下的新目标。没想到,事情开始愈发顺利。随着目标被写明,我们尝试了其他可插拔的模式(solvers),当我们发现旧的目标没有办法对新的问题作出反应时,我们就更新目标;不断重复这个过程。没过多久,现存的可插拔模式我们已经全部看过,我们只得自己设计新的可插拔模式;我们也在这个阶段进行多次迭代。

经过一段时间后,我们意识到最优化设计方法已经被应用到代币设计中!整个逻辑是:规划问题,尝试现有方案;如果有需要,便自行开发。虽然这篇博客将代币设计过程描述为一个 既定事实,但现实中我们也的确是这么做的。我们已经将这套方法用在其他代币设计上,也成功帮助到一些好朋友的项目。

4.2 海洋问题规划

回想一下,我们的目标函数目的是让人们去做某件事。首先,我们必须决定“这些人”是谁。我们必须定义潜在的权益持有者系统代理人。下表描述了海洋协议代币的动态因素:

权益持有者 他们可以提供的价值 他们也许可得的收益
数据/服务供应商、数据保管人、数据拥有者 数据/服务(市场供给) 为得到数据或服务而支付的代币
数据/服务推荐人、管理人(Curator)。包括交易所以及其它应用层供应商 数据/服务(通过供应商,等等),管理(Curation) 为管理而支付的代币
数据/服务验证者。包括其它链上关联证明的解决方案 数据/服务(通过供应商,等等),验证 为验证而支付的代币
数据/服务消费者 代币 数据/服务(市场需求)
维护者 在网络中正确地运行节点 为维护链而支付的代币

目标函数

在上述迭代中,我们最终得到目标函数:将相关的 AI 数据和服务的供给量最大化。这表示除了要刺激人们提供高质量的 有价 数据、高质量的 公共 数据,还要提供相应的计算服务(比如,要保护隐私)。

约束条件

经过上述迭代,我们在做任何设计思考的时候都可以使用这个确认清单。简单来说,我们可以这么思考约束条件:

  • 对于有价数据,是否存在激励手段让我们取得更多?有什么参照?如何防止垃圾数据?
  • 对于公共(免费)数据,是否存在激励手段让我们取得更多?有什么参照?如何防止垃圾数据?
  • 相比于外部投资者,代币对网络使用者来说是否有更高的边际价格?
  • <其他>

除了这些问题,我们也要持续关注可能遭受的攻击;将每个新的关注添加到待解决约束列表中(并取个好记的名称);然后更新设计来因应。像是“数据大逃亡”、“策展克隆”、“爱尔莎和安娜攻击”等等,都适合被涵盖到新的约束中。一些相关的问答内容可以在 Ocean whitepaper 找到,里面也说明了我们处理这些问题的方法。

4.3 探索设计空间

我们尝试过多种代币模式方法,并结合多种设计。也针对上述的条件约束进行测试,以下是我们的尝试:

  • 只有去中心化市场。失败:无法激励参与者提供公共数据。
  • 只有一个参与者 TCR(代币登记节点,Token Curated Registry)(就像 adchain)。失败:无法处理垃圾数据。
  • 只有一个数据/服务 TCR。失败:没办法处理数据逃逸。
  • 一个参与者 TCR,一个 数据/服务 TCR。失败:无法从相关数据/服务辨别垃圾数据。
  • 一个参与者 TCR,一个数据/服务管理市场(CM)。失败:无法激励参与者提供数据/服务。

我们还做了其他多种测试,比如引入不同的治理或声誉系统。最终,我们总算找到了满足需求的条件:一个参与者 TCR,一个数据/服务策展证明市场(CPM),后续会进行说明。

4.4 海洋协议的全新代币模式:证明管理市场

海洋协议的目标函数是:将相关的 AI 数据和服务的供给量最大化

达到这个目标之前,我们必须承认我们无法客观衡量什么是“高质量”。为了解决这个问题,海洋协议将决策权还给 群众:参与者必须使用证明策展市场的一些设定,将自己的钱押注在他们“认为将来会最受欢迎的数据集”上。

然后我们需要调整高质量数据的标志,并向市场提供数据。 要解决这个问题(标记出高质量数据),可以把下列两者整合在一起:预期的受欢迎程度 V.S.实际的(被证明的)受欢迎程度。一个参与者如果满足下面两个条件,就能得到代币奖励:

  1. 他们已在管理市场中预测某数据集的受欢迎程度。这是所谓的预期的受欢迎程度(Predicted Popularity)
  2. 他们已经证明了,在被请求时能提供这样的数据/服务。根据定义,只要提供的东西越受欢迎,收到的请求就越多。称为实际的受欢迎程度(Proofed Popularity)

整个形式我们称之为策展证明市场, Curated Proofs Market (CPM)。策展市场和证明被紧密的绑定在一块儿:证明可以赋予策展市场权威性,使得管理更加行为导向;相对的,策展市场释放出能够证明质量的信号。CPM 是我们正在扩充的代币设计列表中的新元素 :)

下面的公式描述了海洋代币得奖励函数。

4

第一个术语 Sij ,指的是参与者 i 相信的数据/服务 j 的受欢迎程度(预期受欢迎程度);Dj 指的是数据/服务 j 实际的受欢迎程度;T 代表在时间间隔内被分配的代币数;Ri 代表降低某一特定攻击者攻击意愿的向量;预期奖励函数 E() 和比特币一样。海洋协议白皮书中详细阐述了奖励函数是如何运作的。

3. 结论

本文给出了关于使用代币工程工具,进行比特币分析和海洋协议设计的案例。

附录:相关文章和新闻

我在 2018 年 2 月,就本文内容在柏林做过分享,附上投影片录像。我也在同年1月在新墨西哥州圣菲研究所分享复杂系统,附上投影片录像

非常感谢以下的人检查此篇文章以及该系列的其他文章:Ian GriggAlex LangeSimon de la RouviereDimitri de JongheLuis CuendeRyan SelkisKyle Samani 以及Bill Mydlowec。同时也非常感谢和其他人的沟通,包括Anish MohammedRichard CraibFred EhrsamDavid KrakauerTroy McConaghyThomas KolinkoJesse WaldenChris Burniske 以及 Ben Goertzel。最后感谢整个区块链社区,提供了底层基础,使得代币设计成为可能。

附录:相关成果

初版发布后有一些更新。

编辑

  • 2018.3.28 为了便于理解,将 “Proofed Curation Market” 重命名为 “Curated Proofs Market”。

原文链接: https://blog.oceanprotocol.com/token-engineering-case-studies-b44267e68f4
作者: Trent McConaghy
翻译&校对: IAN LIU & 阿剑

本文由作者授权 EthFans 翻译及再出版。


你可能还会喜欢:

干货 | 加密经济学应用的机制设计,Part-1
干货 | 加密货币挖矿的现状
Gnosis和Augur的不同点

 
3 人喜欢