其他
茶话会第一期成功举办,原来 CKB 上的 UDT 可以这么玩
ERC20 回顾与分析
昨晚在 Nervos 社区内举办了第一期 CKB.DEV 茶话会,主要讨论的内容是《如何在 CKB 上发行 UDT》,分享人是 Nervos 社区成员,Nervos 研究员 Cipher·王博老师。
王博老师先分享了关于 CKB 的交易/合约模型,随后分析了 ERC20 存在的问题,最后着重介绍了最小 UDT 的设计和 UDT 扩展功能的设计。
三十多位技术小伙伴全程在线,并在分享结束后展开了激烈的讨论。话不多说,先送上茶话会现场录制视频:
CKB 的交易与合约模型
ERC20 回顾与分析
常见 ERC20 合约提供的方法和事件
ERC20 仅定义了接口,未统一实现。你每创建一个新的 ERC20,都需部署一个新的合约,而用户很难一个个去了解每一个合约。另外由于每个新的合约都是开发者重新创建的,这导致很多的 ERC20 合约或故意或无意地出现了安全问题。 ERC20 接口中用户的行为是耦合的。比如其中的 totalSupply,mint,burn 是管理员的行为;而 balanceOf,approve,transfer 是普通用户的行为,而 allowance,transferFrom 则是授权用户的行为。我们可以看到这一个 ERC20 的合约内至少耦合了三种用户的行为,是相对混乱的。 ERC20 中的逻辑和数据是耦合的。合约的实现逻辑和用户地址下拥有的金额数据都是在这个合约内的,正因为这种耦合,因此以太坊上无法进行统一实现。
逻辑与状态分离,使用统一的业务代码。安全将得到极大的保障。 用户行为、管理员行为、授权行为分离。 仅提供最核心的 UDT 功能。指提供最核心的 UDT 功能,保障开发者对 UDT 灵活性的需求。 采用面向状态,注重行为结果的设计模式,去定义 UDT 的行为。
最小化的 UDT
发币:Create Action
Type Script:用于存放 UDT 创建的逻辑规则,和 UUID 用于描述这个 UDT 的唯一性; Lock Script:简单而言就是签名算法,解释谁可以解开这个 Cell; Data:用于存放 UDT 的定义数据。创建者信息,创建 UDT 数量,小数点尾数等等。
Type Script:用于存放 UDT 转账的逻辑规则,和 UUID 用于描述这个 UDT 的唯一性; Lock Script:简单而言就是签名算法,解释谁可以解开这个 Cell; Data:用于表示 UDT 的余额。
转账:Transfer Action
放入一部分 UDT_BALANCE_CELL(s) 作为 Input。
放入一部分 UDT_BALANCE_CELL(s) 作为 Output。
扩展 Minimal UDT
增发/销毁:Mint/Burn Action
输入 UDT_ID_CELL,当然只有之前 UDT_ID_CELL 中 Lock Script 规定的管理员才可以进行这样的操作,不是谁都可以进行这样的操作的。 (optional) UDT_BALANCE_CELL:如果是销毁,就在这里输入需要销毁的 UDT 的地址和 UDT 数量。
输出新的 UDT_ID_CELL,这是规则发生更改后,新生成的 UDT_ID_CELL; (optional) UDT_BALANCE_CELL:如果是增发,就在这里输入增发的 UDT 需要发送到的地址和 UDT 数量。
授权:Approve/Transfer_from
Action Approve
输入UDT_BALANCE_CELL
输出新的 UDT_BALANCE_CELL_WITH_APPROVE,这是中间状态,表示这个 Cell 处于授权中的状态; Lock: UDT_APPROVE_LOCK:这是一个 Script,其中写入了授权的逻辑规则 授权方信息:授权方的公钥 被授权方信息:被授权方的公钥 授权金额
Action Transfer_from
输入 UDT_BALANCE_CELL_WITH_APPROVE
输出新的 UDT_BALANCE_CELL_WITH_APPROVE,可能授权金额没有完全使用,这是找零; 输出 UDT_BALANCE_CELL,这是被授权方转出的 UDT 部分。
UDT 转账的时候是不是一定需要将一部分 CKB 转账给对方?
Open TX 如何实现?
Mint/Burn Action 操作前后是否会影响,持有地址与该 UDT 合约之间的指向?
...
加入 NC