链下转移：比特币资产协议的演进之路

Taproot Assets 和 RGB 的差异：1）交易的校验与轻节点友好性：Taproot Assets 由于 sum tree 的实现，验证效率和安全性高。RGB 使用的 pedersen 承诺无法有效验证输入的有效性，需要回溯交易历史，后期将是沉重的负担。2）执行 VM：Taproot Assets 使用的 TaprootScriptVM 是比特币 Taproot 升级后自带的脚本执行引擎，vPSBT 是 BTC PSBT 的翻版。一旦闪电通道机制开发完成，可以立刻复用 LND 基础设施和 Lightning labs 产品。且最近火热的 BitVM 提案都基于 TaprootScript。而 RGB 的 VM 和验证规则自成体系，只能在自己的生态里运转，和比特币生态的关系并不紧密。 3）智能合约：当下 RGB 尚未解释 Global State 的修改如何跟各个 UTXO 同步，且 Pedersen 承诺只能对资产总数进行保证。而 Taproot Assets 虽然设计简洁，但目前对于状态的存储也仅有资产余额。4）同步中心：Taproot Assets 可通过 Universe 避免 Proof 丢失问题。而 RGB 中的 Storm 会把链下证明数据通过 p2p 的方式进行同步存储。5）工程实现：Lightning labs 有自己的比特币客户端（BTCD）、闪电网络客户端（LND），以及大量 wallet lib 实现，因此 Taproot Assets 使用的所有 lib 都久经考验。而 RGB 所用的 lib 大部分来自自己定义，从工业标准看尚处于实验室阶段。 客户端验证的资产协议已经脱离了协议范畴，开始迈向计算扩容方向。从应用设计来看，比特币很早选择了不以链上计算为核心目标，而是以验证为主的设计哲学。基于验证实现的视角，有三个扩容方向：验证发生在链上（OP-ZKP）、验证发生在半链上 （BitVM）、验证发生在链下 （Client-Side-Validation、Lightning Network）。当下以太坊流行的 Layer2 从范式上来讲，是通过 Layer1 验证 Layer2 的计算有效性。未来我们可以把验证计算同样下推到链下，进一步释放当下区块链基础设施的性能。\n原文链接