目前个人对于 UDT 的想法主要有几个：它需要是像乐高一样，基础单位足够小、可组织化、可拼接化、可选数量足够多，并且最好可以提供人类可读的模板。
非常喜欢王博老师提出的关于 Minimal UDT 的设计，本文中很大一部分思考也是基于王博老师发表的内容。
王博老师为我们介绍了一种常见的同质化代币的发行方式，将发行和转账作为最基础的操作单元，分别提出了 info_cell 和 balance_cell，然后将销毁/增发，授权转账作为扩展功能予以实现。当然我非常认同这样的设计模式，并在此基础上我希望可以跟进一步。
有没有可能将这些内容和步骤进行进一步的拆分，将整个架构按照乐高积木的形式去进行创造。
比如涉及到的 info_cell 再进行拆分：
name_info_cell，其中包含代币的一些基础信息，如果进行细分的话：
- fullname_name_info_cell：代币全称
- shortname_name_info_cell：代币简称
web_info_cell：代币项目的网址。
additional_info_cell（可能也不叫这个名字）：类似于提供 tokenscript 中描述的内容，token缺失的另一半的相关资料。
supply_info_cell，这里可以提供常见的发行量及小数位数：
- quantitative_supply_info_cell：定量的发行
- function_supply_info_cell：按照某种特定函数进行发行，这里面还可以根据使用的函数类型进行细分，比如 bancor 发行，DAICO，DAIBO 等等
administrator_info_cell，这里的 cell 还会细分为：
- none_adminstrator_info_cell：无超级管理员
- one_adminstrator_info_cell：单人超级管理员
- multi_adminstrator_info_cell：多签下的超级管理员
- vote_adminstrator_info_cell：投票机制下的超级管理员，为链上治理提供解决方案
- script_adminstrator_info_cell：再通过脚本进行深层次的改造
而 balance_cell 也同样根据开发者的设计会有各种各样的选择：
- equal_balance_cell：定义最基本转账条件，输出不能大于输入
- cooling_equal_balance_cell：定义一个冷静期，比如转账完一次后，多久不能进行下一次转账
- unequal_balance_cell：可能输入输出可能是并不相等的，生成或者销毁一部分内容
对于王博老师后面提到的 mint/burn，balance_with_approve_cell 等也可以进行同样的设计。
当然在 minimal UDT 中，我们可能只需要提供最基础最关键的 cell 组件即可。
另外，在此基础上我们需要共同维护这样一个 udt_cell 库，为所有入库和可能入库的 cell 提供合理的命名规则、分类和注解文档，以及安全审计等等，当然可能还需要提供一些典型的将 cell 组件进行组合发行 UDT 的示例。
我并不确定这种乐高式的拼接方式，会不会因为设计上的缺陷造成一些单个组件没有问题，但是组装完成后的整体存在严重漏洞或者缺陷的情况，当然这可能需要在实际开发过程中，进行更多的审计和测试。
此外，我作为一位普通用户，我们很少去真正的了解和阅读我们所持有的 token 背后的智能合约，一方面是由于这可能本来就是一项门槛较高的任务，另一方面是由于目前大部分智能合约都是整体化的，因此很难按照特定的模板进行文字化解读。如果在 CKB 上，script 实现的会更接近于乐高的模式的话，我觉得是不是有可能在一定程度上能提供一些普通用户可读的合约逻辑。
综上，在我看来，在 CKB 上发行同质代币，非同质代币，开展 DAO，ICO，IBO 等行为，并非是一个个孤立的事件。因为它们可能不需要全部使用全新创建的合约，而是演变成只需将所需的多个 cell 多个 script 进行组合即可。
所以我们在 CKB 上要做的是将这些实现逻辑进行独立化、最小化，变成一个个工具，一个个乐高组件。后来的开发者只需要从一大堆已有的组件中找到自己想要的，就可以组装出自己想要的变形金刚了。