本文是基于 Nervos Talk 上公开发表的「关于UDT 标准评估规范的辩论」(https://talk.nervos.org/t/discussion-on-udt-standard-evaluation-criterion/3774) 一文中明确提出的有可能的问题和不切实际的方案。本文主要辩论有哪些有所不同种类的用户不会用于 UDT 模块，UDT 模块应当设置在哪一抽象化层，我们应当反对哪些操作者和查找功能，以及我们的标准为什么必须我们原作一套确认的架构和一系列所需的 Cell，而不是像 ERC20 这样获取非常简单的功能性 API。然后，我将简要地辩论一些架构方案，并获取一份关于 Cell 的可行性、非正式和上层的描述性文档，反对 UDT 操作者和查找功能。

作者：Tannr，Nervos 工程师，享有分布式和 P2P 网络的研发经验，讨厌自学分析哲学和形式系统。原文链接：https://talk.nervos.org/t/approach-to-designing-a-user-defined-token-standard-on-ckb-part-1/3855译者：史迪仔抽象化与编程模块CKB 的编程模型和其他大多数智能合约平台有相当大的有所不同，因为状态分解并会再次发生在 CKB 链上；在 CKB 上，合约只是脚本，用作检验继续执行它们的账户否有效地。

这样的原作，对于设计 UDT 标准来说，有两点意义值得注意：意义 1：查找模块 → 标准化数据定位第一个影响是，合约会获取可由外部调用的催促—号召或基于事件的模块。这些合约会作为查找模块回到查找信息，也会作为账户模块产生链上副反应。这意味著在 CKB 上，为智能合约设置查找模块是没意义的。

毫无疑问，查找 Token 信息的功能是至关重要的，因此就明确提出了一个问题：如果不是由智能合约获取的 API，那应当是什么？查找程序可以采访节点获取的 RPC API，只要向这些 RPC 获取参数，并通报 API 服务器明确的查询方位，节点就可以采访链数据。所以，标准化智能合约的逻辑是适当的，但这并足以反对在 CKB 上展开 UDT 查找：我们必需标准化关键 UDT 数据的存储方位，以便服务器可以精彩地查询到该数据。为了标准化 UDT 数据的存储方位，我们必需标准化由 Cell 构成的大于适当架构。

在这个设计过程中，我们应当忘记，标准应当是可拓展的，这样才可以适应环境各种用例。在像 ERC20 这样的标准中，智能合约的功能亲笔签名和预期返回值都是登录的，而构建细节完全几乎由开发人员要求。

相比之下，CKB-UDT 标准拒绝我们最少必须登录一个基础结构（以及某些明确的构建细节），这容许了开发人员建构自定义 Token。灵活性和可扩展性是 Nervos Network 高度重视的价值观，所以尽管基本架构设计规范是必需的，但还是要十分留意，尽可能不要壮烈牺牲灵活性和可扩展性。意义 2 ：编程模块 → 账户规则集第二个影响是 CKB 上的智能合约，虽然写出在 Cell 内，但实质上是账户层面的规则集。

这些合约 —— 从现在开始称作「脚本」 —— 在账户环境中继续执行。它们可以采访账户的所有信息，而不仅仅限于它们所相连的 Cell。

当然，账户可以在其有所不同的 Cell 中包括多个脚本。因此，可以将脚本看做是账户的整个规则集的特定子集，其中规则集是每个脚本内规则的子集。账户，而不是脚本，在网络上构建状态变化。

当开发人员期望在 Ethereum 上部署自定义编程不道德时，他们的重点在智能合约的不道德。而在 CKB 上，把重点放到账户不道德上（账户叙述了一组状态的变更或不道德），然后获取研发脚本来继续执行账户规则，这样做到更有意义。换句话说，虽然许多智能合约平台注目于构建自定义编程不道德的智能合约，但 CKB 使用账户优先的方法。

账户的设计是最重要的；脚本的不存在意味着是为了保证遵循交易账户设计的规则。因此，虽然在一个典型的智能合约平台上的自定义 Token 标准将为智能合约定义一个编程模块，通过有所不同的合约函数与 Token 操作者相关联，但在 CKB 上的自定义 Token 标准将定义一个账户优先的模块，通过有所不同的账户结构与特定的 UDT 操作者涉及。UDT 标准的拒绝在设计 CKB-UDT 标准的第一步是要理解谁将用于它和为什么用于它。这将告诉我们必须反对哪些具体操作和查找功能。

具体操作将被同构到账户规则集，而查找将被同构到标准化的数据方位、大小和格式。由于账户受到规则集的约束，规则集是账户继续执行时在结构和内容上的规则，因此登录账户规则集还必须登录大于适当结构。正如我在上面一节中提及的，鉴于 CKB 的编程模型，登录标准化结构是不可避免的。

用户用户主要是 DApp 开发人员、钱包、交易所和其他代表终端用户继续执行状态分解或查找的服务。我在这里没提及 Holder，也没提及 DApp 用户，因为前者和后者都是通过其他界面用于 UDT 的。因此，实质上，只有 Token、DApp 以及离链软件服务的开发人员才不会必要与 CKB-UDT 展开交互。

再行将用户分成三种有所不同类型中的一种或多种：开发人员、生成器和查询器。此上下文中的开发人员是那些必要专门从事某个自定义 Token 的开发人员。

生成器是指递交 UDT-specific 账户的任一外部服务，而查询器是指查找 UDT-specific 信息的任一外部服务。在更进一步辩论 UDT 标准应当反对的实际查找和状态变更之前，解读在 Nervos Network 上明确提出的任何特定规则都必须受到整个系统的约束，这十分最重要。成本容许UDT-specific 账户所须要继续执行脚本的计算出来支出。

在链上存储 UDT-specific 状态的容量成本。账户成本是指继续执行一项操作者必须多少笔账户，以及每笔账户的大小（这不会影响账户手续费）。可用性约束可扩展性，使开发人员需要在标准相容的前提下建构和自定义他们的 Token。

查找复杂度，用作查询器搜集和解析涉及信息，还包括搜集必须包括在账户中的信息。UDT 使用度，各不相同重新加入新的功能来反对一种新的 UDT，必须展开多少工作。我们在 UDT 标准中反对的操作者和查找功能，最后必须符合各种有所不同的用例，还包括自定义货币政策、为产品自定义发售计划以及与其他 DApp 的互操作性。留意：鉴于 CKB 的编程模型，将 UDT-specific 的账户继续执行规则的脚本和用户实际持有人 Token 解法耦。

用户在 Cell 中持有人的实际 Token，我将称作「UDT 实例」，而负责管理存储系统级信息和继续执行账户规则集的元数据和脚本子集是我将总称为「UDT 定义」。后面将详尽讲解。查找和操作者查找查找某地址下 UDT 余额提供 UDT 元数据提供 UDT 账户的倚赖项取得 UDT 实例的实际使用者取得 UDT 定义的实际创建者从定义中取得 UDT 实例的实际创立器汇聚持有人该 UDT 实例下的地址操作者（状态变更）发送到 UDT 实例批准后 UDT 实例的使用者焚毁 UDT 实例创立新的 UDT 实例改版 UDT 定义创立具有初始 UDT 实例供应的新 UDT 定义架构规范设计这个规范的挑战之一是每一个决策都约束着后面的决策。

基础的架构规范对于解释账户结构和规则，以及解释应当如何展开数据查询、查找都至关重要。我们必须架构规范来明确提出账户分解和查找规则（因为账户和查找并不意味著必须登录所牵涉到的 Cell），但是我们又必须交易分解和查找规则来解读哪些架构决策，从一开始就是最有意义的……这或许是循环的。所以我要做到的是确认一些可行性的架构，用于这个可行性的架构来设计账户规则集和查找操作者，然后标明改动这个架构的哪些部分，可以更佳地反对实际的规则。

CKB 编程模型的第一个架构决策 —— 或者有可能是架构特征 —— 是状态更改的逻辑和受该逻辑约束的实际状态的分离出来。对于状态的任何组成部分（例如，Cell 或 Cell 子集），在将来可能会发生变化，必需有另一个包括检验逻辑的状态组件。这里留意，「状态组件」是一个逻辑组件，因为它所指的是一个或多个 Cell。

因此，如果我们有用作人们展开账户处置的 UDT 实例，那么我们必需有第二个 Cell，它包括这些 UDT 实例的检验逻辑。我称作「UDT 定义」。由于我们期望需要改版检验逻辑以减低某些情况（如安全漏洞或在 UDT 用户批准后下容许我们展开策略变更），因此我们必需有第三个 Cell，其中包括改版这些 UDT 定义的检验逻辑，我称作「UDT 标准」。除了元数据之外：上面我提及过，UDT 定义某种程度是检验逻辑，而且还包括所有不属于 UDT 实例的元数据。

问题是: 在哪里存储这些元数据？元数据应当有自己的 Cell 吗？否应当将其作为 agrs 存储在 UDT 定义的脚本（即「UDT 标准」）内？即使某些 UDT 的元数据和检验逻辑被拆分成分开的 Cell，这些 Cell 依然总称为「UDT 定义」。因此，我用于的 UDT 分类法不一定 1:1 同构到实际的 Cell；它是一种逻辑分类法，而不是物理分类法。因此，这个架构分成三层：UDT 实例UDT 定义UDT 标准UDT 标准容许了牵涉到 UDT 定义的有效地账户，而 UDT 定义容许了各自 UDT 实例的有效地账户。

Nervos 获取与开发人员获取的 UDT 标准 Cell在 UDT 标准层面，1个 UDT 标准不会有很多 UDT 定义。在 UDT 定义层面，一个 UDT 定义不会有很多 UDT 实例。

问题是：如果开发人员负责管理构建 UDT 定义，那么他们否也负责管理建构 UDT 标准，还是应当由 Nervos Network 获取？我们的目标是容许灵活性的货币、管理和发售政策，因此有两种方式可以前进。第一种方法是为社区开发人员获取一个 UDT 标准 Cell，并通过 args 使其具备充足的可配备性。

第二种方法是获取 UDT 标准必需强制执行的大于规则集，然后开发人员可以以他们期望的任何方式建构 UDT 标准 Cell，只要它符合适当的规则。如果我们最后期望将元数据存储为 args 发送到 DUT 标准 Cell，那么 args 的顺序和含义必须标准化，以便其他服务器可以检索元数据。如果标准 Cell 是由 Nervos Network 获取的，这不会更容易，因为 args 可以通过编程构建。

但是，如果容许开发人员建构自己的 UDT 标准 Cell，他们可以省略某些可选功能，网卓新闻网，而不必须通过 args 将其配备为停止使用。想象一下下面的场景：Nervos Network 获取的 UDT 标准 Cell，容许在初始供应之后铸新的 Token，通过落成或停止使用 w/a 布尔型 arg，并设置铸的额外参数（例如一次多少，否有利益相关者投票，批准后某些铸者作为签订者等）。他们的确必须可升级性，所以他们将可升级性设置为 true，并用于另一个 arginclude 展开额外的配备。

现在，无论何时升级 UDT 定义，UDT 标准 Cell 都包括这一段校验代码，从而减少了不必要的账户大小。但是，如果他们建构自己的 UDT 标准 Cell，他们可以省略与其用例牵涉到的任何功能。一个有可能的解决方案是标准化 args，而不管在其 UDT 标准脚本中实际包括了哪些代码。因此，即使标准脚本不将第三个 arg 视作「可移除的标志」，它们依然必须在那里包括一个「false」值，以指出它不能移除，并且必需撰写脚本以忽视该标志。

然而，这是一个「陈腐」的解决方案。元数据作为 UDT 定义与元数据 Cell 的参数但是，想象一下另一种情况，即元数据（例如总供应量）存储在元数据 Cell 中，而不是脚本中。这些元数据中的一部分是脚本所必须的。

例如，在减少或增加供应（铸或封存）的情况下，对脚本展开采访提供总供应量十分最重要。因此，将总供应量作为 args 包括到脚本中比存储在几乎有所不同的 Cell 中更容易。回应有两种解决方案。第一种是创立一个元数据 Cell，并通过一个 arg 获取具有 outpoint 的脚本。

那么账户必需在 deps 字段中将这个 outpoint 设置为 dep。脚本将以这种方式读取元数据并展开检验改版或创立。这样做到的问题在于，读取数据必须额外的计算出来支出。

幸运地的是，CKB 编程反对部分数据读取。第二种解决方案是合并元数据；一部分存储在 args 中，一部分存储在元数据 Cell 中。Args 将存储对状态变更逻辑至关重要的元数据，而其他元数据将存储在元数据 Cell 中。

但是，这使得整个事情变得复杂，因为现在元数据存储在两个地方，一些与一个脚本的检验逻辑涉及的元数据有可能与其他脚本的检验逻辑涉及。例如，totalSupply 对铸和封存十分最重要，但是封存也可以由 Holder 继续执行。在 Cell 中存储元数据还获取了更大的可扩展性，因为开发人员可以将额外的元数据存储在更加简单的数据结构中。

因此，对包括脚本涉及数据的 Cell（元数据 Cell）的提到可以作为 arg 展开传送。在设计元数据 Cell 的结构时，我们必须保证脚本涉及字段是序列化的，这样脚本可以部分读取数据，而不用读取元数据 Cell 的全部内容，因为一些元数据片段将与某些特定的脚本涉及，而另一些则会。

例如，如果数据存储为从键到值的同构，为了读取一个或两个互为关键，脚本必需读取整个同构。列表结构容许部分读取，但是我们必需确认如何处置可选数据。在同构中，键可以被省略。在列表结构中，被省略的键会转变其他元数据的字节地址，因此依然必须读取整个列表。

一种解决方案是标准化字节地址及其含义（例如，第一个 x 位是专门用作名称的），省略一个附加的元数据片段用「null 字节序列」回应。这里的权衡是，如果开发人员期望从元数据 Cell 中省略某一部分数据，他们依然必须闲置相等于存储每一部分元数据所须要容量的容量，而不管某些部分否被指出是附加的。

Hashmaps 从一开始就闲置了更加多的空间。具有两个键值对的 Hashmaps 比具有两个元素的数组闲置更好的空间。因此，在最坏的情况下，当包括所有附加的元数据时，基于数组的结构闲置的空间较较少，并且反对部分读取，而同构则不反对。

我们必需要求用于哪种数据结构，无论是列表、同构还是其他数据结构。准确的序列化方法可以解决问题这些问题中的一些问题，但是在这种情况下，脚本和查询器都会有额外的反序列化支出。作为锁住和类型脚本的 UDT 标准UDT 标准 Cell 用作为在 UDT 定义上继续执行的操作者获取检验逻辑。

还包括权限管理以及保证有效地的状态变更和数据一致性。根据 CKB 的编程模型，有效地的状态变更是由类型脚本展开处置的，而权限是由锁住脚本处置的。因此 UDT 标准在物理上由两个 Cell 构成 —— 一个锁住脚本和一个类型脚本。

意外的是，这使得开发人员的工作变得复杂，因为他们必须存储的 Cell 就越多，研发越少的 UDT 就必须首先享有更好的容量。但是，容许他们研发自己的 UDT 标准 Cell 可以移除校验代码，从而节省容量。

所以这是一个权衡。或许最差的解决方案是为想用于标准 Cell 的开发人员获取标准 Cell（因为这样也节省了研发时间），而开发人员也可以权利地研发合乎他们想反对的附加操作者的 UDT 标准 Cell，只要所需的规则集是由他们的自定义脚本强制执行的。到目前为止的架构阐述UDT 实例UDT 定义 —— 类型脚本 Cell；元数据单元UDT 标准 —— 类型脚本 Cell；瞄准脚本 CellPart 1 总结在本文中，我说明了账户是 CKB 研发的主要编程模块，而不是脚本。

我明确提出了一组 UDT 标准应当反对的操作者和查找，说明了为什么我们的 UDT 标准必须为社区研发的 UDT 登录一个特定架构，然后叙述了一个上层的 UDT 架构，这个架构意味着是反对所须要操作者和查找所必须的一组单元。在下一篇文章中，我将深入研究账户规则集，然后基于这些规则集，更加了解地叙述 UDT 架构。

例如，如果改版了 UDT 定义，那么 UDT 实例对 UDT 定义的提到就不应当维持有效地，因此，UDT 标准必需强制执行类似于 Type ID 功能的操作者。另一个例子，UDT 定义应当获取防伪维护，但是初始供应的 UDT 创立必需跨过这一点。

如何设计 UDT 创立操作者（通过获取类似权限、用于重复使用许可等）这不会影响哪些 args 并传送给哪些脚本，等等。

本文来源：aifa官方入口-www.dousangmk.com