原文作者：Guy Wuollet

原文标题：7 Sanity Checks Before Designing a Token

原文来源：a16z

编译：Yvonne，MarsBit

代币是一种功能强大的新原语，可以通过多种方式进行定义；我在这里讨论了为什么我们应该考虑代币的研究和设计，而不仅仅是“代币经济学”。

代币显然允许非常丰富的设计。但我们仍处于探索的早期阶段，更不用说改进代币设计了。这里要达到的圣杯将是计算机科学家通常所说的“the Dragon Book”的现代版本。这本书指的是《编译器：原理、技术和工具》（作者：Alfred Aho、Monica Lam、Ravi Sethi 和 Jeffrey Ullman；有时也可以参考该书的早期版本或 Aho 和 Ullman 的旧作《编译器设计原理)》 — 统一、定义并影响了几代计算机科学家对编译器设计的研究。就在几年前，两位作者因为“编程语言实现的基础算法和理论”以及“在他们极具影响力的书籍中综合了这些结果和其他人的结果，这些结果教育了一代又一代的计算机科学家”而获得了ACM图灵奖。我们距见到代币设计的“the Dragon Book”还很远——现在就代币制定明确的文本还为时过早。我们的研究负责人 Tim Roughgarden 指出，虽然我们距离这一目标可能还有不到十年的时间，但这是一项持续的工作。因为 Dragon Book 帮助将 1950 年代“难以置信的混乱”、庞大的大型计算机科学问题——编译器设计——变成了一个更容易解决的问题，可以分阶段解决，在每个阶段应用严格的原则。

但一些早期的机会和陷阱已经变得清晰起来——所以我认为，如果我整理了一份清单，列出我们团队在与其他人合作进行代币设计时经常讨论的一些合理性检查，将会对建设者有所帮助。我还鼓励你观看Eddy Lazzarin最近关于代币设计的演讲，其中涵盖心智模型、常见模式和陷阱、当前代币功能以及许多有待探索的设计领域。

实际情况是，许多努力为其项目寻找“正确”代币设计的团队往往在没有经过测试的设计框架的情况下工作——因此遇到了与其他人相同的挑战。幸运的是，也有早期的成功和“好的”代币设计的例子。最有效的代币模型将具有其目标所特有的元素，但大多数有缺陷的代币设计都有许多常见的陷阱。因此，这里有一个指导性提示列表，可以避免最常见的错误模式。

1.设立一个明确的目标

代币设计中最大的痛苦来自于，在尚未明确说明目标之前就构建一个复杂的模型。没有好代币模型或坏代币模型一说——只有一个代币模型是否可以实现你的目标。

第一步应该是严格审视目标，并确保你（和你的团队）完全理解它：它是什么，它为什么重要，你真正想要完成什么？未能严格定义目标通常会导致重新设计和浪费时间。明确定义目标还有助于避免“为了代币经济学而进行代币经济学”的问题，这是对某些代币设计的常见（并非不公平）批评。

此外，目标应该特定于代币。这似乎很明显，但经常被忽视。此类目标的示例包括：

一款希望能够最好地实现可扩展性和支持封装的代币模型的游戏。

一个 DeFi 协议，想要设计一个代币模型，在参与者之间最佳地分配风险。

一个希望保证文件低延迟可用的存储网络。

一个希望提供最大经济安全性的质押网络。

一种希望带来最大参与度的治理机制。

……这个名单可以继续下去。代币可以支持任何用例和目标——而不是相反。

那么你如何开始定义一个明确的目标？明确定义的目标通常来自愿景。虽然愿景往往是虚无缥缈和抽象的，但目标应该是具体的并简化为最基本的形式。

让我们以EIP-1559为例。Roughgarden将EIP-1559的目标表述得最好:“EIP-1559应该在需求快速增长的时期之外，以‘明显的最佳出价’的形式，通过简单的费用估算来改善用户体验。”

他继续提出了另一个明确的目标： “我们能否重新设计以太坊的交易费用机制，让设置交易的 gas 价格更像是在亚马逊上购物？理想的是发布价格机制，这意味着一种机制为每个用户提供一个接受或放弃的 gas 价格以包含在下一个区块中。我们会看到……EIP-1559 中提出的交易费用机制就像一个定价机制，除非需求突然大量增加……”

这两个例子的共同点是陈述了一个高层次的目标；提供相关的类比（在这种情况下可能）以帮助其他人理解该目标；然后着手概述最能支持该目标的设计。

2.根据基本原则评估现有模型

在创造新事物时，研究已经存在的事物总是一个好主意。当你评估现有协议和现有资料时，你应该根据它们的技术优点客观地评估它们。

代币模型通常根据代币的价格或相关项目的受欢迎程度进行评估。这些因素可能与代币模型满足其既定目标的能力无关。估值、受欢迎程度或其他评估代币模型的幼稚方法可能会使构建者误入歧途。

如果你假设其他代币模型正常运行，而它们却不能正常运行，那么你就会创建一个有瑕疵的代币模型。如果你用不同的目标重新使用一个代币模型，你可以隐含地继承那些对你的代币模型没有意义的假设。

3.阐明猜想

明确阐述你的猜想。当你专注于构建代币时，很容易将基本猜想视为理所当然。也很容易不正确地阐明你真正的猜想。

让我们以一个假设其硬件瓶颈是计算速度的新协议为例。使用该假设作为代币模型的一部分——例如，通过限制参与协议所需的硬件成本——可以帮助使设计与期望的行为保持一致。

但是，如果协议和代币设计者没有陈述他们的猜想——或者他们陈述的猜想是错误的——那么意识到不匹配的参与者就有可能从协议中提取价值。“黑客”通常是比最初构建系统的人更了解系统的人。

阐明你的猜想可以更容易地理解你的代币设计并确保它正常工作。如果不阐明你的猜想，你也无法验证你的猜想……

4.验证猜想

俗话说：让你陷入麻烦的，不是你不知道的事，而是你自以为知道、其实错误的事。” （这句话通常被认为是马克·吐温和其他人所说，随着时间的推移，这句话也不断演变。）

代币模型通常会做出一组假设。这种方法部分来自拜占庭系统设计的历史，作为区块链的灵感来源。系统做出假设并构建一个函数，如果假设为真，则可以保证一定的输出。例如：比特币保证同步网络模型的活性，如果网络中 51% 的算力是诚实的，则保证一致性。几个小型区块链遭到 51% 的攻击，这违反了中本聪共识对区块链正常运行的假设，即多数节点诚实。

代币设计者可以通过多种方式验证他们的猜想。严格的统计建模（通常以基于主体的模型的形式）可以帮助检验这些猜想。关于人类行为的假设通常也可以通过与用户交谈来验证，更好的是，通过观察人们实际做了什么（而不是说他们做了什么）。这是可能的，尤其是通过在沙盒环境中产生经验结果的激励测试网。

形式验证或密集的审计也将有助于确保代码库按预期运行。

5.定义明确的抽象障碍

“抽象障碍”是系统或协议不同层次之间的接口。它用于分离系统的不同组件，允许每个组件独立设计、实现和修改。明确的抽象障碍在所有工程领域都有用，尤其是软件设计，但对于分布式开发和构建单人无法理解的复杂系统的大型团队来说更是必要的。

在代币设计中，明确抽象障碍的目标是将复杂性降至最低。减少代币模型的不同组件之间的（相互）依赖性会带来更清晰的代码、更少的错误和更好的代币设计。

举个例子：许多区块链是由大型工程团队构建的。一个团队可能会随着时间的推移对硬件成本做出假设，并使用它来确定有多少矿工以给定的代币价格为区块链贡献硬件。如果另一个团队依赖代币价格作为参数，但不知道第一个团队对硬件成本的假设，他们很容易做出相互矛盾的猜想。

在应用层，清晰的抽象障碍对于实现可组合性至关重要。随着越来越多的协议相互组合，匹配、构建、扩展和重新混合的能力只会变得越来越重要。更大的组合会带来更大的可能性，但也会带来更大的复杂性。当应用程序想要组合时，它们必须了解它们所组合的协议的细节。

不透明的假设和接口偶尔会导致模糊的错误，尤其是在早期的 DeFi 协议中。晦涩的抽象障碍也延长了开发时间，因为它增加了不同团队在沟通协议组件方面的沟通时间。模糊的抽象障碍也增加了协议的整体复杂性，使任何一个人都难以完全理解该机制。

通过创建清晰的抽象障碍，代币设计者可以更轻松地预测特定更改将如何影响代币设计的每个部分。确的抽象障碍还可以更容易地扩展代币或协议，并创建一个更具包容性和扩张性的开发者社区。

6.减少对外生参数的依赖

外生参数不是系统固有的，但会影响整体性能和成功——例如计算资源的成本、吞吐量或延迟——通常用于创建代币模型。

危险的是，当代币模型仅在参数保持在有限范围内时才起作用，可能会出现意外行为。例如，思考一个出售服务并以固定代币奖励形式提供回扣的协议：如果代币价格出乎意料地高，则代币奖励的价值可能大于服务成本。在这种情况下，从协议中购买无限量的服务是有利可图的，这会导致奖励用完或服务被充分利用。

或者再举一个例子：去中心化网络通常依赖于密码学或计算难题，这些难题很难解决，但并非不可能解决。这些难题的难度通常取决于外生变量——比如计算机计算哈希函数或零知识证明的速度。想象一个协议，它假设计算给定哈希函数的速度有多快，并相应地支付代币奖励。如果有人发明了一种新方法来更快地计算该哈希函数，或者只是拥有超大资源来解决与他们在系统中的实际工作不成比例的问题，他们可以获得意想不到的巨额代币奖励。

7.重新验证猜想

设计代币应该像设计对抗系统一样。假设拜占庭式的行为。用户的行为将随着代币工作方式的改变而改变。

一个常见的错误是，在不确保用户行为仍会导致可接受结果的情况下，调整自己的代币模型。不要假设用户行为会随着代币模型的变化而保持不变。通常这个错误发生在设计过程的后期：有人花了很多时间来定义代币的目标、功能，并进行验证以确保它按预期工作。然后他们确定一个边缘案例并改变代币设计以适应它……但忘记重新验证整个代币模型。通过修复一个边缘案例，他们造成了另一个（或其他几个）意想不到的后果。（注：边缘案例是指，在电脑编程中，只出现在可能值范围的最高或最低端或极端情况下的问题或情况）

不要让辛勤工作付之东流：每当项目更改代币模型时，都要重新验证它是否按预期工作。