RGB 实现了资产定义与保管机制的分化，好处是什么？

[keroro520]

对于 《RGB 的真正潜能》 一文中的 #资产定义与保管机制的分化 章节有个疑问。

在这里，UTXO 的脚本和 RGB 协议形成了功能上的分化：前者致力于实现价值保管和价值转移的规则；而后者专注于资产定义。从而，资产的保管和资产的定义可以拆分开来。这是一种重要的安全性提升，也是人们在一些别的链上合约系统中孜孜以求的东西。

想问一下，为什么说 资产保管和资产定义的可拆分 是一种安全性的提升呢？体现在什么方面呢？

[keroro520]

我理解 Nervos CKB 分离了 cell 的 lock script 和 type script，前者负责资产保管（所有权的转移），后者负责资产定义（业务逻辑）。
这两种 script 分别对应资产保管和资产定义，但我感觉这种分化只是提升了脚本的可组合性，即不同的 lock script 可以组合不同的 type script。但是这种分化有什么安全性的提升呢？

[editor-Ajian]

lock script 归 lock script，type script 归 type script。前者并不用来组合后者，后者也不用来组合前者。是否某些特性需要两者的一对一搭配，我没有了解过。
的确，两者都可以内省另一者（也即都可以对另一者施加一些约束），但这种内省不是默认动用的，需要额外设计。所以，定义资产的代码不需要考虑用户怎么保管这种资产（用户用什么 lock script，使用 type script 来定义资产的开发者不需要关心），也不需要在自己的代码中实现保管方法，也不需要担心代码交互问题。用户自己愿意用多签，用单签，用模拟账户，都可以。资产合约的开发者不需要关心，也不需要提供适配，Cell 自身即是接口。

[editor-Ajian]

可以把它跟 “资产定义和保管机制混合” 的形式对比，来理解这种安全性上的好处。
这里我们以 “以太坊的智能合约账户” 为例。在这种模式中，资产的定义（这些资产到底对应着什么样的权利）和保管（资产如何转移）都由相应的智能合约账户来决定，而 EOA（用户账户）只能通过交易向对应的账户发送指令，来调用相应的操作。这样的合约账户就要面对这两种本质上不同面向的代码有无可能互动从而引发 bug 的问题。
但在两者分离的模式中（尤其是比特币 UTXO），这两种代码是不会互动的。负责保管的代码只验证花费的有效性，而不管被转移的是什么东西；而定义资产的代码也不会定义怎么保管它（尽管的确有可能实现一些限制，但可以认为默认情况是不限制）。自然而然，因为代码交互而出错的可能性就大大减小了。

[keroro520]

感谢回答❤️ ~了解，目的是减少复杂度（随便啥词儿，职责分离、模块化、轻耦合。。），从而降低出错的可能性。