《a16z：关于Token设计的 7 点小建议》
作者：Guy Wuollet
编译：星球日报ODAILY
Token是一种强大的新原语，可以用多种方式定义。Token设计空间非常丰富，但我们仍处于探索的早期阶段。
实际上，许多团队努力为他们的项目找到「正确的」Token设计。但行业本就缺乏经过测试的设计框架，因此后人反复遭遇和前人同样的挑战。幸运的是，也有（少数）早期的成功的Token设计的例子。大多数有效的Token模型都有针对其目标的独特元素，但大多数有缺陷的Token设计都有一些常见的 Bug。因此，本文将讨论为什么我们应该考虑Token的研究和设计，而不仅仅是「Token经济」，并列出了七项「避坑」小技巧。
1 明确Token的目标
Token设计中最大的问题是在明确目标之前如何构建复杂的Token模型。第一步应该是确定目标，并确保整个团队能够完全理解：它是什么，它为什么重要，你真正想要完成什么？未能严格定义目标通常会导致重新设计和浪费时间。明确目标还有助于避免「为设计Token经济而捏造出一Token经济」的问题，这是某些Token经济设计的常见现象。
此外，目标应该围绕Token本身进行，但这一点往往被忽视。明确目标的例子包括：
设计一个Token模型的游戏，该模型可实现最佳可扩展性和支持建模。
一个 DeFi 协议希望设计一个Token模型，在参与者之间合理分配风险。
设计一个担保金钱的信誉协议不能直接替代信誉（例如，通过将流动性与信誉信号分离）。
设计一个能够保证文件在低延迟情况下可用的存储网络。
设计一个能够提供最大经济安全性的质押网络。
设计一个能够引出真正用户偏好或最大参与度的治理机制。
这样的例子不胜枚举。让Token可以支持任何用例和达到任何目标，而不是反其道而行。
那么如何开始定义一个清晰的目标呢？明确定义的目标通常来自于「项目使命」。虽然「项目使命」往往是高层次和抽象的，但目标应该是具体的，并简化为最基本的形式。
让我们以 EIP-1559 为例。Roughgarden 对 EIP-1559 的一个明确目标表述：「EIP-1559 应该在需求快速增长的时期之外，以『明显的最佳出价』的形式，通过简单的费用估算来改善用户体验。」
他接着提出了另一个明确的目标：「我们能否重新设计以太坊的交易费用机制，让设定交易 Gas 价格更像在亚马逊上购物般『丝滑』？最理想的是价格发布机制，这意味着一种为每个用户提供一个接受或放弃 Gas 价格的机制」。
这两个例子的共同点是陈述了一个高层次的目标，提供一个相关的类比来帮助其他人理解你的目标，然后继续勾勒出最能支持这一目标的设计方案。
2 根据基本原则评估现有工作
在创造新事物时，从已有的东西下手研究是一个好主意。当你评估现有协议和现有文献时，应根据其技术优点对其进行客观评估。
Token模型通常根据Token的价格或相关项目的受欢迎程度进行评估。这些因素可能与Token模型实现其既定目标的能力无关。估值、受欢迎程度或其他评估Token模型的简单方法可能会导致 Builder「多走弯路」。如果你假设其他Token模型正常运行，而实际上它们不能正常运行，那么可能会创建一个「天生带有缺陷」的Token模型。
3 阐明你的假设
明确表达你的假设。当你专注于构建Token时，很容易将基本假设视为理所当然。也很容易错误地表达你真正做出的假设。
以一个新协议为例，该协议假设其硬件瓶颈是计算速度。将该假设作为Token模型的一部分（例如，通过限制参与协议所需的硬件成本）可以帮助将设计与期望的行为保持一致。
但是，如果协议和Token设计者没有明确表达他们的假设，或者他们表达的假设是错误的。那么意识到这种不匹配的参与者就有可能从协议中提取价值。黑客通常是那些比最初构建系统的人更了解系统的人。
阐明你的假设可以让人更容易地理解你的Token设计并确保其正常运行。如果不明确你的假设，你也无法验证你的假设。
4 验证你的假设
有句话说：「不是你不知道的事情让你陷入困境。而是你确信的事情并非如此。」
Token模型通常会做出一系列假设。这种方法部分来自拜占庭系统设计，这是区块链的灵感来源。系统做了一个假设，并建立了一个函数，如果假设为真，则可以保证一定的输出。例如，比特币保证了同步网络模型中的活动性，如果网络中 51% 的哈希算力是诚实的，则保证一致性。几个较小的区块链遭到了 51% 的攻击，违反了中本聪共识要求区块链正常运行的诚实假设数量。
Token设计者可以通过多种方式验证他们的假设。严格的统计建模，通常以基于代理的模型的形式，可以帮助测试这些假设。关于用户行为的假设通常也可以通过与用户交谈来验证，更好是通过观察人们实际做了什么（而不是说他们做了什么）来验证。这样成功验证的可能性较高，尤其是通过在沙盒环境中产生经验结果的激励测试网络。正式的验证或密集的审计也将有助于确保代码库按预期的方式运行。
5 明确「抽象障碍」
「抽象障碍」（abstraction barrier）是系统或协议的不同层次之间的界面。它用于分离系统的不同组件，允许独立地设计、实现和修改每个组件。清晰的抽象障碍在所有工程领域，尤其是软件设计领域都是有用的，但是对于去中心化开发和大型团队构建个体无法理解的复杂系统来说更是必要的。
在Token设计中，清除抽象障碍的目标是最小化复杂性。减少Token模型的不同组件之间的（内部）依赖关系可以产生更简洁的代码、更少的 Bug 和更好的Token设计。
举个例子，许多区块链都是由大型工程团队构建的。一个团队可能会对一段时间内的硬件成本进行假设，并用它来确定有多少矿工以给定的Token价格为区块链贡献硬件。如果另一个团队依赖Token价格作为参数，但不知道第一个团队对硬件成本的假设，他们很容易做出相互矛盾的假设。
在应用程序层，明确的抽象障碍对于实现可组合性至关重要。随着越来越多的协议相互组合，适应、构建、扩展和重新混合的能力只会变得越来越重要。更大的构成带来更大的可能性，但也带来更大的复杂性。当应用程序想要组合时，它们必须理解它们所使用的组合协议的细节。
不透明的假设和界面偶尔会导致模糊的 Bug，特别是在早期的 DeFi 协议中。模糊的抽象障碍还增加了处理协议不同组件的团队之间所需的通信效率，从而延长了开发时间。模糊的抽象障碍也增加了协议的复杂性，使得很难完全理解其机制。
通过创建明确的抽象障碍，Token设计者可以更容易地预测特定的更改将如何影响Token设计的每个部分。明确的抽象障碍也使扩展Token或协议变得更容易，并创建一个更具包容性和扩展性的 Builder 社区。
6 减少对外部参数的依赖
外部参数不是系统固有的，但会影响整体性能和成败，例如在代Token模型的创建初期的计算资源的成本、交易量或延迟。
但当Token模型仅在参数保持在有限范围内时才起作用时，可能会出现意外行为。例如，一个出售服务并以固定Token奖励的形式提供回扣的协议，如果Token的价格出乎意料地高，则Token奖励的价值可能大于服务的成本。在这种情况下，从协议中购买无限量的服务相当划算，这会充分利用Token奖励和服务。
或者再举一个例子，去中心化网络通常依赖于加密算法或计算难题，这些难题解决难度大，但并非不可能解决。难度通常取决于一个外生变量，比如计算机计算哈希函数或零知识证明的速度有多快。比如有一个协议，它假设计算给定哈希函数的速度有多快，并相应地支付Token奖励。如果有人发明了一种更快地计算哈希函数的新方法，或者只是拥有与他们在系统中的实际工作不成比例的超大资源来解决问题，他们就可以获得意想不到的巨额Token奖励。
7 重新验证假设
设计一个Token应该像设计一个对抗系统一样。用户的行为将随着Token工作方式的改变而改变。
一个常见的错误是在没有确保任意用户行为仍能产生可接受的结果的情况下调整Token模型。不要认为用户行为会因Token模型的变化而保持不变。通常这种错误会在设计过程的后期发生，有人花了很多时间来定义Token的目标，定义其功能，并进行验证以确保其按预期运行。然后，他们确定了一个特例，并改变了Token设计以适应它，但忘记了重新验证整个Token模型。通过修复一个特例，他们产生了另一个（或其他几个）意想不到的后果。
记住不要让辛苦的工作白费，每当项目更改其Token模型时，都要重新验证它是否按预期运行。
文章来源于互联网:a16z：关于Token设计的7点小建议