a16z：早期代币设计中的7个关键问题

原文：《7 Sanity Checks Before Designing a Token》by Guy Wuollet

编译：Sissi

代币是一种非常强大的新型原语，可以通过多种方式定义；在文章「Tokenology：超越代币经济学」中已经阐述了为什么我们应该将代币的研究和设计考虑得更广泛，而不仅仅是“代币经济学”。

代币为设计带来了非常丰富的空间。但是我们仍处于探索代币设计的早期阶段，更不用说改进了。在这里，我们所追求的圣杯就是计算机科学家常常称之为“龙书”的现代版。这本书指的是《编译原理》（由Alfred Aho、Monica Lam、Ravi Sethi 和 Jeffrey Ullman 所著），有时也可能指早期版本的该书或 Aho 和 Ullman 的早期作品《编译器设计原理》。该书统一、定义并影响了几代计算机科学家对编译器设计的研究。它影响了许多人，以至于该书的两位作者在几年前被授予了ACM图灵奖，其中一位是“为编程语言实现打下基础的算法和理论”，另一位是“通过在他们的高度影响力的书籍中综合这些结果和其他人的成果，教育了几代计算机科学家”。

我们距离像编译器设计领域里的“龙书”那样的代表性著作还有很长的路要走，现在要编写一本关于代币的权威指南还为时过早。我们的研究主管Tim Roughgarden指出，距离这个目标可能还需要十年左右的时间，这是一项长期的工作。在20世纪50年代，编译器设计是一个非常复杂和混乱的计算机科学难题。《龙书》的出现，通过阶段性应用严格的原则，帮助将这个问题转化为了一个更好解决的问题。

但一些早期的机会和陷阱已经变得清晰起来了。因此，我认为，如果我整理一份我们团队在与其他人进行代币设计时经常讨论的一些合理性检查列表，那么这对于那些正在构建代币的人将是有帮助的。我还鼓励大家观看 Eddy Lazzarin 最近关于代币设计的演讲，其中涵盖了心理模型、常见模式和陷阱、当前代币的功能以及许多尚未探索的设计空间。

实际情况是，许多团队试图为自己的项目找到“正确”的代币设计，但通常缺乏测试过的设计框架，因此遇到了其他人曾经遇到的相同挑战。幸运的是，也存在早期的成功案例和“好”的代币设计示例。最有效的代币模型将具有与其目标独特的元素，但大多数有缺陷的代币设计都共享一些常见的缺陷。因此，这里列出了一些有用的提示，以避免最常见的失败模式。

#1 设定明确的目标

在设计代币时**的困难是在明确目标之前构建一个复杂的模型。没有所谓的好代币设计或坏代币设计——只有实现你的目标的代币设计或者没有实现目标的代币设计。

第一步应该始终是严谨地审视目标，并确保你（和你的团队）充分理解它：是什么，为什么重要，你真正想要实现什么？没有严谨地定义目标通常会导致重新设计和浪费时间。明确定义目标还有助于避免“为了代币经济而代币经济”的问题，这是对一些代币设计的常见（而且不无道理的）批评。

此外，目标应该针对代币具体而言。这可能看起来很显然，但经常被忽视。以下是一些具体的代币目标示例：

• 一个游戏想要设计一个**的代币模型，以实现可扩展性并支持模组化

• 一个 DeFi 协议想要设计一个**的代币模型，以在参与者之间分配风险

• 一个声誉协议想要确保资金不能直接用于声誉（例如，通过将流动性与声誉信号分离）

• 一个存储网络想要保证文件低延迟可用

• 一个质押网络想要提供**的经济安全

• 一个治理机制想要获取真实偏好或**参与度。 ……列表可以不胜枚举。代币可以支持任何用例和目标，而不是反过来

那么，如何开始明确目标呢？明确的目标通常来自于一份使命宣言。虽然使命宣言往往是高层次和抽象的，但目标应该是具体和简化到最基本的形式。

我们以 EIP-1559 为例。Roughgarden 提出的 EIP-1559 的一个明确目标是：“EIP-1559 应通过易于估算费用的优化方式，改善用户体验，使其在需求急剧上升时，能够以‘显而易见的**出价’的形式存在。“

他还提出了另一个明确的目标：“我们是否可以重新设计以太坊的交易费用机制，使得设置交易的 gas 价格更像在亚马逊购物？理想的情况是一个公布价格的机制，即为每个用户提供一个接受或放弃的 gas 价格，以便在下一个区块中包含。我们将看到…在 EIP-1559 中提出的交易费用机制就像一个公布价格的机制，除非需求大幅度增加。

这两个例子共同之处在于：阐述了一个高层次的目标；提供了一个易于理解的类比，以帮助他人理解这个目标；然后继续概述**支持该目标的设计。

#2 从第一原理出发评估现有工作

在创建新事物时，研究已经存在的东西通常是个好主意。当你评估现有协议和文献时，应该客观地从技术优劣的角度来评价它们。

代币模型经常基于代币价格或相关项目的受欢迎程度进行评估。这些因素可能与代币模型实现其目标的能力无关。估值、受欢迎程度或其他单纯的评估代币模型的方法可能会让构建者走入歧途。

如果你认为其它模型能够正常工作，但实际上它们不能，那么你就可能会创建一个有缺陷的代币模型。如果你为了不同的目标重新使用一个代币模型，你可能会不经意地继承不适合你的代币模型的假设。

#3 阐明假设

当你专注于构建一个代币时，很容易将基本假设视为理所当然。你也很容易错误地表述你真正做出的假设。

让我们以一个新协议为例，假设它的硬件瓶颈是计算速度。将这种假设作为代币模型的一部分（例如，限制参与协议所需的硬件成本）可以帮助将设计与期望的行为对齐。

但是，如果协议和代币设计者没有陈述他们的假设，或者他们陈述的假设是错误的，那么可能会有参与者意识到偏差并从协议中提取价值。“黑客”通常是那些比系统的设计者更了解系统的人。

阐述你的假设可以使人更容易理解你的代币设计，并确保其正常工作。如果没有明确表述你的假设，你也无法验证你的假设……

#4 验证假设

俗话说，“让你陷入麻烦的不是你不知道的，而是你肯定知道但并非如此的事情。”

代币模型通常会做出一系列假设。这种方法部分源于拜占庭系统设计的历史，作为区块链的灵感来源。该系统做出假设，并构建一个函数，如果该假设成立，则保证一些输出。例如：比特币保证在同步网络模型中的活跃性，并且如果网络中的51%的哈希功率是诚实的，则保证一致性。有几个较小的区块链已经遭受了51%攻击，违反了纳克莫托共识对区块链正确运行所需的诚实多数假设。

代币设计者可以通过多种方式验证他们的假设。严谨的统计建模，通常以Agent-Based建模的形式，可以帮助测试这些假设。有关人类行为的假设也经常通过与用户交谈并观察人们实际做的事情（而不是他们所说的）来验证，特别是通过激励测试网络在沙盒环境中生成实证结果。

正式验证或密集审核也有助于确保代码库按预期运行。

#5 定义清晰的抽象屏障

“抽象屏障”是系统或协议不同层次之间的接口。它用于分离系统的不同组件，使每个组件可以独立设计、实现和修改。清晰的抽象屏障在所有工程领域特别是软件设计中都很有用，对于分散式开发和大团队构建复杂系统更是必要，因为单个人无法理解整个系统。

在代币设计中，清晰的抽象屏障的目标是尽量减少复杂性。减少代币模型不同组件之间的相互依赖性可以得到更干净的代码，更少的漏洞和更好的代币设计。

例如，许多区块链是由大型工程团队构建的。一组可能会假设硬件成本随时间变化而改变，并使用该假设来确定为特定代币价格提供多少挖矿设备。如果另一组依赖于代币价格作为参数，但不知道第一个团队对硬件成本的假设，那么它们可能会做出冲突的假设。

不透明的假设和接口有时会导致难以发现的错误，特别是在早期的 DeFi 协议中。模糊的抽象屏障还通过增加协议不同组件的团队之间的沟通来延长开发时间。模糊的抽象屏障还增加了整个协议的复杂性，使任何一个人都难以完全理解该机制。

通过创建清晰的抽象屏障，代币设计者可以更容易地预测特定的更改将如何影响代币设计的每个部分。清晰的抽象屏障还使扩展自己的代币或协议更加容易，并创建一个更包容和广泛的建设者社区。

#6 减少对外部参数的依赖

在创建代币模型时，经常会使用一些对于系统本身不是固有参数，但会影响整体性能和成功的外部参数，如计算资源的成本、吞吐量或延迟等。

在创建代币模型时，经常会使用一些对于系统本身不是固有参数，但会影响整体性能和成功的外在参数，比如计算资源的成本、吞吐量或延迟等。

危险的是，当代币模型仅在某些参数保持在有限范围内时才能正常工作，就会出现意外行为。例如，考虑一个协议，它销售某项服务并以一定数量的代币奖励形式提供返利：如果代币价格意外飙升，代币奖励的价值可能会超过服务的成本。在这种情况下，从该协议购买无限数量的服务是有利可图的，从而导致奖励用尽或服务被完全利用。

再举一个例子：去中心化网络通常依赖于加密或计算难题，这些难题非常困难，但并非不可能解决。这些难题的难度通常取决于外部变量，比如计算机可以计算哈希函数或零知识证明的速度。想象一下一个协议，它假设能够快速计算某个哈希函数的速度，并相应地支付代币奖励。如果有人发明了一种更快地计算该哈希函数的方法，或者只是拥有不成比例的巨大资源来解决该问题，他们就可以获得意外的大量代币奖励。

#7重新验证假设

设计一个代币应该像设计一个对抗性系统那样。假设系统中存在拜占庭行为（即可能有不忠诚的节点）。用户的行为会随着代币运行方式的变化而发生改变。

设计者常犯的一个错误是在调整代币模型时没有确保任意用户行为仍然能产生可接受的结果。不要假设用户行为在代币模型变化时会保持不变。这种错误通常发生在设计过程的后期：有人花费了大量时间定义代币的目标、功能，并验证其是否按预期工作。然后，他们识别出一个边缘案例并调整代币设计以适应它……但是忘记了重新验证整个代币模型。他们在解决一个边缘案例时，可能会产生另一个（或几个）意外后果。

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