24 Sep 2021

Token Engineering Case Studies:Analysis of Bitcoin, Design of Ocean Protocol

Case Study: Analysis of Bitcoin

让我们从优化设计的角度来构建比特币，关注比特币的目标函数。

其目标函数为： 最大限度地提高其网络的安全性。

然后它将“安全性”定义为计算能力（哈希率），这使得回滚对事务日志的更改变得昂贵。

它的区块奖励功能通过向提高网络计算能力的人提供区块奖励代币 (BTC) 来体现，我们可以写出目标函数（奖励函数）的公式，如下图所示。

左侧是参与者我可以预期的区块间隔内的代币奖励量R。

等式的右侧与左侧成正比 (α)，是参与者i的计算能力（哈希率）与每个区块T分配的代币数量的乘积。

后者的价值目前是每十分钟 12.5 BTC。该奖励每四年减半。

请注意，奖励是根据预期值E()。这意味着每个用户不一定在每个时间间隔都会收到一个区块奖励。相反，在比特币，这是相当粗笨：只是一个单一的用户在每个块间隔奖励。

为什么比特币会有这种块状（高方差），而不是在每个时间间隔（低方差）奖励每个玩家？以下是一些好处：

• 它不需要跟踪每个用户贡献了多少。因此较低的计算和较低的带宽。
• 它不需要在每个时间间隔向每个用户发送 BTC。因此交易更少，带宽更低。效率调整！
• 由于不需要前两个，系统可以简单得多，因此可以最大限度地减少攻击面。因此更简单，更安全。

这些都是显着的好处。最大的负面影响是更高的方差：要真正有机会赢得任何东西，您需要显着的哈希率，尽管如果您赢了，您将赢得大奖。然而，这种更高的方差可以通过更高级别的矿池来缓解，这具有减少方差的直接效果。

Case Study: Design of Ocean Protocol

当我们于 2017 年 5 月开始为Ocean Protocol进行认真的代币设计时，我们发现自己在挣扎。我们没有制定目标（目标和约束），而只是着眼于像去中心化市场这样的现成解决方案。但随后我们问：这对数据共享有何帮助？它没有。这需要自己的令牌吗？它不需要。

When we first started doing serious token design for Ocean Protocol in May 2017, we found ourselves struggling. We hadn’t formulated the goals (objectives and constraints) and instead were simply looking at plug-and-play patterns like decentralized marketplaces. But then we asked: how does this help the data commons? It didn’t. Does this need its own token? It didn’t. And there were other issues.

因此，我们退后了一步，给自己设定了编写适当目标和约束的目标。然后，事情开始变得顺利。写下这些目标后，我们尝试了其他现有方案。我们发现了目标未反映的新问题，因此我们更新了目标。我们在这个迭代过程中不断循环。没过多久，我们就测完了现有方案，因此我们不得不设计自己的模式；我们对这些进行了迭代。

So, we took a step back and gave ourselves the goal of writing proper objectives and constraints. Then, things started to go smoother. With those goals written down, we tried other plug-and-play patterns (solvers). We found new issues that the goals didn’t reflect, so we updated the goals. We kept looping in this iterative process. It didn’t take long before we’d exhausted existing plug-and-play patterns, so we had to design our own; and we iterated on those.

这样做了一段时间后，我们意识到我们一直在将优化器设计方法应用于代币设计！即：将问题表述出来，尝试使用现有的模式；如果需要，然后开发自己的。因此，虽然这篇博文将代币设计过程描述为既成事实，但实际上我们在做的时候发现了它。我们实际上已经将这种方法用于其他代币设计，以帮助他们项目中的朋友。

After doing this for a while, we realized that we had been applying the optimizer design approach to token design! That is: formulate the problem, try using existing patterns; and if needed then develop your own. So while this blog post lays out the token design process as a fait accompli, in reality we discovered it as we were doing it. We’ve actually used this methodology for other token designs since, to help out friends in their projects.

Ocean Problem Formulation

目标函数是关于让人们做事，所以，我们必须首先确定这些人是谁。我们必须定义可能的利益相关者或代理。下表概述了 Ocean 令牌动态的关键。

Recall that the objective function is about getting people to do stuff. So, we must first decide who those people are. We must define the possible stakeholders or system agents. The following table outlines the key ones for Ocean token dynamics.

学习更多

https://blog.oceanprotocol.com/token-engineering-case-studies-b44267e68f4