原文来自： Random idea: compact sUDT / xUDT cell
CKB 与其他区块链不同，因为将 sUDT 放置在 cell 中，所以也有 CKB 存储的需求。这段时间以来，我们做了一些探索，也已经提出了几种不同的解决方案。每种方法都有其优点和缺点。然而，仍然有一些用例在这里不能完全满足。
最近在 CKB上 的 Sparse Merkle Tree, SMT 也有了一些发展。我们已经看到了它在一些场景的用例，以及它如何帮助确保 CKB 中可变长度数据的恒定空间需求。这就带来了一个想法:如果我们将 SMT 引入 sUDT 来解决链上存储需求会怎样?
我们可以设计一个 Compact （紧凑的） sUDT cell ，如下所示:
Lock: <compact sUDT lock>
Type: sUDT type script
Data: <16 byte sUDT amount> <32 byte SMT root>
乍一看，这与典型的 sUDT cell 非常相似，除了32字节的 SMT root 外。SMT root 实际上追踪者不同的持有Token 的用户的余额表。例如，一个包含 100 个某 sUDT 的 Compact sUDT cell 可能会保持如下的余额表:
| 拥有者 | 数量 |
|---|---|
| Alice | 21 |
| Bob | 33 |
| Charlie | 56 |
这里的一个潜在场景是交易所: 一个交易所可能为每种类的 sUDT 生成一个或多个 Compact sUDT cell，这些 Compact sUDT cell 可以完美地处理提款： 当用户从一个中心化交易所取款时，交易所只需要用更新的记录修改 sUDT cell 即可 。例如，如果 Alice 提取 50 个sUDT，交易所使用与上面一样的 compact sUDT cell，这个 cell 只需要更新，因此 Alice 现在有 71 个 sUDT, 50 个新的该 sUDT token 也将被转移到这个 cell 。
例如，如果 Bob 想从 Compact sUDT cell 中取款，Bob 可以通过证明他的身份来生成一个交易，因此 Compact sUDT lock 可以验证 Bob 的身份，并检查 SMT 中的余额，并接受或拒绝 Bob 的取款申请。
这样一来，我们就有了一个合适的 sUDT cell ，它可以保存许多余额，且只需占用恒定的存储空间（ckbyte）。在某种程度上，我们可以将其视为 Approve Cell 的扩展，您将同时持有多个用户的余额，而不是单单一个用户的余额就消耗一个 cell。
Cell 争用
当然， Compact cell 可能存在着对 cell 的争用情况，某人可能试图存款，而另一个人则可能试图提取。而且很有可能它们都试图使用同一个 Compact sUDT cell ，这将导致竞争。但是另一种思考这个问题的方式是，Compact sUDT cell 也会是一个 Open Transaction 设计的完美用例。无论您是存取款，都不需要提供完整的交易，人们只需要提供他们关心和需要的部分交易，然后一个如矿工般的代理机构，会完整的将一笔笔交易拼凑在一起，送到 CKB 链上然后等待处理。
xUDT
您可能已经注意到，我故意漏掉了一个问题:谁来验证 SMT 证明逻辑?假设我现在将 10 个 sUDT 存入一个Compact sUDT cell，是什么阻止我在余额表中修给我自己 10 万个sUDT ?事实证明，对于 sUDT 来说，可能还没有适合这种逻辑的地方，但对于 xUDT 来说，验证逻辑可以完美地保存在标准规范的扩展中。所以 Compact sUDT cell 可能不是真正好用的东西，但 Compact xUDT cell 是。
未来
这只是一些粗略的想法，我真的不知道这样做是否有意义，或者下一步要做什么，或者是否真的需要一个Compell xUDT cell 。欢迎任何类型的评论。
译者注：常常听到社区中有人在讨论每个 sUDT cell 到每位不同的人手中就必须占用 142 ckb，这对一资产管理的服务商来说，会不会是很大的一种成本和负担？看到学姐的致密 sUDT cell，似乎能有效的减少许多 CKByte 占用所带来的负担，很期待之后这样的巧思能够在更多场景开花，让对于很多没有心理准备要消耗多 ckbyte 的用户可以有个使用上更经济的方案，展现了 CKB 在各情况下都存在的可选择性和弹性。