可是，想象一下另一种环境，即元数据（譬喻总供给量）存储在元数据 Cell 中，而不是剧本中。这些元数据中的一部门是剧本所必须的。譬喻，在增加或淘汰供给（锻造或销毁）的环境下，对剧本举办会见获取总供给量很是重要。因此，将总供给量作为 args 包括到剧本中比存储在完全差异的 Cell 中更容易。
在设计元数据 Cell 的布局时，我们需要确保脚内情关字段是序列化的，这样剧本可以部门加载数据，而不必加载元数据 Cell 的全部内容，因为一些元数据片断将与某些特定的脚内情关，而另一些则不会。譬喻，假如数据存储为从键到值的映射，为了加载一个或两个相要害，剧本必需加载整个映射。列表布局答允部门加载，可是我们必需确定如那里理惩罚可选数据。在映射中，键可以被省略。在列表布局中，被省略的键会改变其他元数据的字节地点，因此仍然需要加载整个列表。
想象一下下面的场景：Nervos Network 提供的 UDT 尺度 Cell，答允在初始供给之后锻造新的 Token，通过启用或禁用 w/a 布尔型 arg，并配置锻造的特别参数（譬喻一次几多，是否有好处相关者投票，核准某些锻造者作为签署者等）。他们简直需要可进级性，所以他们将可进级性配置为 true，并利用另一个 arg & include 举办特另外设置。
作为锁和范例剧本的 UDT 尺度
UDT-specific 转账所需执行剧本的计较开销。
用户主要是 DApp 开拓人员、钱包、生意业务所和其他代表终端用户执行状态生成或查询的处事。我在这里没有提到 Holder，也没有提到 DApp 用户，因为前者和后者都是通过其他界面利用 UDT 的。因此，实际上，只有 Token、DApp 以及离链软件处事的开拓人员才会直接与 CKB-UDT 举办交互。
建设带有初始 UDT 实例供给的新 UDT 界说
在下一篇文章中，我将深入研究转账法则集，然后基于这些法则集，更深入地描写 UDT 架构。譬喻，假如更新了 UDT 界说，那么 UDT 实例对 UDT 界说的引用就不该该保持有效，因此，UDT 尺度必需强制执行雷同于 Type ID 成果的操纵。另一个例子，UDT 界说应该提供防伪掩护，可是初始供给的 UDT 建设必需绕过这一点。如何设计 UDT 建设操纵（通过提供非凡权限、利用一次性授权等）这会影响哪些 args 并通报给哪些剧本，等等。设计这个类型的挑战之一是每一个决定都约束着后头的决定。基本的架构类型对付说明转账布局和法则，以及说明应该如何举办数据查找、查询都至关重要。我们需要架构类型来提出转账生成和查询法则（因为转账和查询并不料味着需要指定所涉及的 Cell），可是我们又需要生意业务生成和查询法则来领略哪些架构决定，从一开始就是最有意义的……这好像是轮回的。
更新 UDT 界说
烧毁 UDT 实例
CKB 的编程模子和其他大大都智能合约平台有很大的差异，因为状态生成并不会产生在 CKB 链上；在 CKB 上，合约只是剧本，用于验证执行它们的转账是否有效。这样的设定，对付设计 UDT 尺度来说，有两点意义值得留意：
得到 UDT 界说的实际建设者
译者：史迪仔
UDT 实例
用户
从界说中得到 UDT 实例的实际建设器
因此，这个架构分为三层：
除了元数据之外：上面我提到过，UDT 界说不只仅是验证逻辑，并且还包罗所有不属于 UDT 实例的元数据。问题是: 在那边存储这些元数据？元数据应该有本身的 Cell 吗？是否应该将其作为 agrs 存储在 UDT 界说的剧本（即「UDT 尺度」）内？纵然某些 UDT 的元数据和验证逻辑被支解成单独的 Cell，这些 Cell 仍然统称为「UDT 界说」。因此，我利用的 UDT 分类法不必然 1:1 映射到实际的 Cell；它是一种逻辑分类法，而不是物理分类法。
元数据作为 UDT 界说与元数据 Cell 的参数
此刻，无论何时进级 UDT 界说，UDT 尺度 Cell 都包括这一段冗余代码，从而增加了不须要的转账巨细。可是，假如他们构建本身的 UDT 尺度 Cell，他们可以省略与其用例无关的任何成果。一个大概的办理方案是尺度化 args，而不管在其 UDT 尺度剧本中实际包括了哪些代码。因此，纵然尺度剧本不将第三个 arg 视为「可删除的符号」，它们仍然需要在哪里包括一个「false」值，以表白它不行删除，而且必需编写剧本以忽略该符号。然而，这是一个「古老」的办理方案。
我们的方针是答允机动的钱币、管理和刊行政策，因此有两种方法可以推进。第一种要领是为社区开拓人员提供一个 UDT 尺度 Cell，并通过 args 使其具有足够的可设置性。第二种要领是提供 UDT 尺度必需强制执行的最小法则集，然后开拓人员可以以他们但愿的任何方法构建 UDT 尺度 Cell，只要它满意须要的法则。
UDT 界说
UDT 尺度
Hashmaps 从一开始就占用了更多的空间。带有两个键值对的 Hashmaps 比带有两个元素的数组占用更多的空间。因此，在最坏的环境下，当包括所有可选的元数据时，基于数组的布局占用的空间较少，而且支持部门加载，而映射则不支持。我们必需抉择利用哪种数据布局，无论是列表、映射照旧其他数据布局。正确的序列化要领可以办理这些问题中的一些问题，可是在这种环境下，剧本和查询器城市有特另外反序列化开销。
所以我要做的是确定一些劈头的架构，利用这个劈头的架构来设计转账法则集和查询操纵，然后标明修改这个架构的哪些部门，可以更好地支持实际的法则。
得到 UDT 实例的实际利用者
本文是基于 Nervos Talk 上颁发的「关于UDT 尺度评估类型的接头」(https://talk.nervos.org/t/discussion-on-udt-standard-evaluation-criterion/3774) 一文中提出的大概的问题和可行的方案。
搜集持有该 UDT 实例下的地点
获取 UDT 元数据
在设计 CKB-UDT 尺度的第一步是要相识谁将利用它和为什么利用它。这将奉告我们需要支持哪些详细操纵和查询成果。详细操纵将被映射到转账法则集，而查询将被映射到尺度化的数据位置、巨细和名目。由于转账受到法则集的约束，法则集是转账执行时在布局和内容上的法则，因此指定转账法则集还需要指定最小须要布局。正如我在上面一节中提到的，鉴于 CKB 的编程模子，指定尺度化布局是不行制止的。
第一个影响是，合约不会提供可由外部挪用的请求—响应或基于事件的接口。这些合约不会作为查询接口返回查询信息，也不会作为转账接口发生链上副回响。这意味着在 CKB 上，为智能合约配置查询接口是没有意义的。毫无疑问，查询 Token 信息的成果是至关重要的，因此就提出了一个问题：假如不是由智能合约提供的 API，那应该是什么？查询措施可以会见节点提供的 RPC API，只要向这些 RPC 提供参数，并通知 API 处事器详细的查找位置，节点就可以会见链数据。所以，尺度化智能合约的逻辑是须要的，但这并不敷以支持在 CKB 长举办 UDT 查询：我们必需尺度化要害 UDT 数据的存储位置，以便处事器可以轻松地查找到该数据。
不幸的是，这使得开拓人员的事情变得巨大，因为他们需要存储的 Cell 越多，开拓越多的 UDT 就需要首先拥有更多的容量。可是，答允他们开拓本身的 UDT 尺度 Cell 可以删除冗余代码，从而节减容量。所以这是一个衡量。也许最好的办理方案是为想要利用尺度 Cell 的开拓人员提供尺度 Cell（因为这样也节减了开拓时间），而开拓人员也可以自由地开拓切合他们想要支持的可选操纵的 UDT 尺度 Cell，只要所需的法则集是由他们的自界说剧本强制执行的。
第二个影响是 CKB 上的智能合约，固然写在 Cell 内，但实际上是转账层面的法则集。这些合约 —— 以后刻开始称为「剧本」 —— 在转账情况中执行。它们可以会见转账的所有信息，而不只限于它们所毗连的 Cell。虽然，转账可以在其差异的 Cell 中包括多个剧本。因此，可以将剧本看作是转账的整个法则集的特定子集，个中法则集是每个剧本内法则的荟萃。转账，而不是剧本，在网络上实近况态变革。
查询某地点下 UDT 余额
第二种办理方案是拆分元数据；一部门存储在 args 中，一部门存储在元数据 Cell 中。Args 将存储对状态变动逻辑至关重要的元数据，而其他元数据将存储在元数据 Cell 中。可是，，这使得整个工作变得巨大，因为此刻元数据存储在两个处所，一些与一个剧本的验证逻辑相关的元数据大概与其他剧本的验证逻辑相关。譬喻，totalSupply 对锻造和销毁十分重要，可是销毁也可以由 Holder 执行。在 Cell 中存储元数据还提供了更大的可扩展性，因为开拓人员可以将特另外元数据存储在更巨大的数据布局中。因此，对包括脚内情关数据的 Cell（元数据 Cell）的引用可以作为 arg 举办通报。
本文主要接头有哪些差异种类的用户会利用 UDT 接口，UDT 接口应该配置在哪一抽象层，我们应该支持哪些操纵和查询成果，以及我们的尺度为什么需要我们设定一套确定的架构和一系列所需的 Cell，而不是像 ERC20 这样提供简朴的成果性 API。然后，我将简腹地接头一些架构方案，并提供一份关于 Cell 的劈头、非正式和上层的描写性文档，支持 UDT 操纵和查询成果。
核准 UDT 实例的利用者
在本文中，我说明白转账是 CKB 开拓的主要编程接口，而不是剧本。我提出了一组 UDT 尺度应该支持的操纵和查询，表明白为什么我们的 UDT 尺度需要为社区开拓的 UDT 指定一个特定架构，然后描写了一个上层的 UDT 架构，这个架构仅仅是支持所需操纵和查询所必须的一组单位。
我们在 UDT 尺度中支持的操纵和查询成果，最终需要满意各类差异的用例，包罗定制钱币政策、为产物定制刊行打算以及与其他 DApp 的互操纵性。
意义 2 ：编程接口 → 转账法则集
UDT 尺度限制了涉及 UDT 界说的有效转账，而 UDT 界说限制了各自 UDT 实例的有效转账。
发送 UDT 实例
可扩展性，使开拓人员可以或许在尺度兼容的前提下构建和自界说他们的 Token。
抽象与编程接口
UDT 尺度的要求
在链上存储 UDT-specific 状态的容量本钱。
建设新的 UDT 实例
假如我们最终但愿将元数据存储为 args 发送到 DUT 尺度 Cell，那么 args 的顺序和寄义需要尺度化，以便其他处事器可以检索元数据。假如尺度 Cell 是由 Nervos Network 提供的，这会更容易，因为 args 可以通过编程实现。可是，假如答允开拓人员构建本身的 UDT 尺度 Cell，他们可以省略某些可选成果，而不需要通过 args 将其设置为禁用。
再将用户分为三种差异范例中的一种或多种：开拓人员、生成器和查询器。此上下文中的开拓人员是那些直接从事某个自界说 Token 的开拓人员。生成器是指提交 UDT-specific 转账的任一外部处事，而查询器是指查询 UDT-specific 信息的任一外部处事。
作者：Tannr，Nervos 工程师，拥有漫衍式和 P2P 网络的开拓履历，喜欢进修阐明哲学和形式系统。
UDT 界说 —— 范例剧本 Cell；元数据单位
一种办理方案是尺度化字节地点及其寄义（譬喻，第一个 x 位是专门用于名称的），省略一个可选的元数据片断用「null 字节序列」暗示。这里的衡量是，假如开拓人员但愿从元数据 Cell 中省略某一部门数据，他们仍然需要占用相当于存储每一部门元数据所需容量的容量，而不管某些部门是否被认为是可选的。
在进一步接头 UDT 尺度应该支持的实际查询和状态变动之前，领略在 Nervos Network 上提出的任何特定法则都需要受到整个系统的约束，这十分重要。
查询和操纵
因此，假如我们有用于人们举办转账处理惩罚的 UDT 实例，那么我们必需有第二个 Cell，它包括这些 UDT 实例的验证逻辑。我称之为「UDT 界说」。由于我们但愿可以或许更新验证逻辑以减轻某些环境（如安详裂痕或在 UDT 用户核准下答允我们举办计策变动），因此我们必需有第三个 Cell，个中包括更新这些 UDT 界说的验证逻辑，我称之为「UDT 尺度」。
在 UDT 尺度层面，1个 UDT 尺度会有许多 UDT 界说。在 UDT 界说层面，一个 UDT 界说会有许多 UDT 实例。
获取 UDT 转账的依赖项
当开拓人员但愿在 Ethereum 上陈设自界说编程行为时，他们的重点在智能合约的行为。而在 CKB 上，把重点放在转账行为上（转账描写了一组状态的变动或行为），然后提供开拓脚原来执行转账法则，这样做更有意义。换句话说，固然很多智能合约平台存眷于实现自界说编程行为的智能合约，但 CKB 回收转账优先的要领。转账的设计是最重要的；剧本的存在仅仅是为了确保遵循生意业务转账设计的法则。因此，固然在一个典范的智能合约平台上的自界说 Token 尺度将为智能合约界说一个编程接口，通过差异的合约函数与 Token 操纵相关联，但在 CKB 上的自界说 Token 尺度将界说一个转账优先的接口，通过差异的转账布局与特定的 UDT 操纵相关。
查询
操纵（状态变动）
UDT 尺度 —— 范例剧本 Cell；锁定剧本 Cell
查询巨大度，用于查询器收集息争析相关信息，包罗收集需要包括在转账中的信息。
转账本钱是指执行一项操纵需要几多笔转账，以及每笔转账的巨细（这会影响转账手续费）。
Part 1 总结
到今朝为止的架构概述
留意：鉴于 CKB 的编程模子，将 UDT-specific 的转账执行法则的剧本和用户实际持有 Token 解耦。用户在 Cell 中持有的实际 Token，我将称之为「UDT 实例」，而认真存储系统级信息和执行转账法则集的元数据和剧本荟萃是我将统称为「UDT 界说」。后头将具体先容。
UDT 回收度，取决于插手新的成果来支持一种新的 UDT，需要举办几多事情。
问题是：假如开拓人员认真实现 UDT 界说，那么他们是否也认真构建 UDT 尺度，照旧应该由 Nervos Network 提供？
CKB 编程模子的第一个架构决定 —— 可能大概是架构特征 —— 是状态改观的逻辑和受该逻辑约束的实际状态的疏散。对付状态的任何构成部门（譬喻，Cell 或 Cell 荟萃），在未来大概会产生变革，必需有另一个包括验证逻辑的状态组件。这里留意，「状态组件」是一个逻辑组件，因为它指的是一个或多个 Cell。
Nervos 提供与开拓人员提供的 UDT 尺度 Cell
UDT 实例
可用性约束
架构类型
意义 1：查询接口 → 尺度化数据定位
本钱限制
原文链接：https://talk.nervos.org/t/approach-to-designing-a-user-defined-token-standard-on-ckb-part-1/3855
为了尺度化 UDT 数据的存储位置，我们必需尺度化由 Cell 构成的最小须要架构。在这个设计进程中，我们应该记着，尺度应该是可扩展的，这样才可以适应各类用例。在像 ERC20 这样的尺度中，智能条约的成果签名和预期返回值都是指定的，而实现细节险些完全由开拓人员抉择。对比之下，CKB-UDT 尺度要求我们至少需要指定一个基本布局（以及某些详细的实现细节），这限制了开拓人员构建自界说 Token。机动性和可扩展性是 Nervos Network 高度重视的代价观，所以尽量根基架构设计类型是必需的，但照旧要很是留意，只管不要牺牲机动性和可扩展性。
对此有两种办理方案。第一种是建设一个元数据 Cell，并通过一个 arg 提供带有 outpoint 的剧本。那么转账必需在 deps 字段中将这个 outpoint 配置为 dep。剧本将以这种方法加载元数据并举办验证更新或建设。这样做的问题在于，加载数据需要特另外计较开销。幸运的是，CKB 编程支持部门数据加载。
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
