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

前言

基于 BTC 去做资产发行，一直都是一个热点话题。从最早在 2011 年出现的 Colored Coins 到近来大火的 Ordinal 协议，BTC 社区其实总能涌现出新的玩家和共识，但是能留下的寥寥无几。但随着野心勃勃的 Lightling Labs 宣布自己在 Taproot Assets 至上构建 Stable Coin 的计划，Tether 也宣布将选择 RGB 进行 USDT 在比特币一层的铸造。

这代表着曾经名噪一时的 OmniLayer(Mastercoin) 不再是 BTC 生态最大的玩家，客户端验证 (CSV) 资产协议由开始进入大家的视野，与传统的 BTC 资产协议的不同在于，它们还带上了为 BTC 扩容的属性。但是面对 BTC 生态如此繁多的资产协议，人们不禁要问，他们的差别在哪里，面对如此众多的资产协议，我们该如何去选择和并且从中找到自己的机会。

本文旨在引导读者回顾比特币历史上出现的各种资产协议，深入研究基于比特币的资产协议在可预见的未来发展的潜在轨迹。

染色币：Colored Coins

Colored Coins 的想法最早由 Yoni Assia，现 eToro 的 CEO，在 2012 年 3 月 27 日的编写的一篇名为bitcoin 2.X (aka Colored bitcoin)文章提出。文章认为比特币作为底层技术是完美的，就像 HTTP 是网络的基础一样。因此在复用 BTC 的基础上去设计了 Colored Coins 这个代币协议。

Yoni Assia 希望通过这样的形式创建 BTC2.0 的经济 - 任何社区都可以通过这种方式来创建多种货币。这种将比特币作为底层技术用于清算交易和避免双重支付的方式在当时无疑于是非常大胆的想法。

Colored Coins 作为一种基于比特币发行资产的协议，其做法就是将一定数量的比特币“上色”以表示这些资产。这些标记的比特币在功能上仍然是比特币，但它们同时也代表了另一个资产或价值。但是这样的想法该如何在比特币上实现呢？

2014 年 7 月 3 日，ChromaWay 开发了增强型基于填充订单的着色协议（EPOBC），该协议简化了开发人员制造彩色硬币的过程，这便是最早采用 Bitcoin Script 的 OP_RETURN 功能的协议。

最终实现的效果如下图所示：

这样的实现非常简洁，但是由此也带来了很多问题：

同质化代币与最小绑定值

在创世交易中为某个染色币绑定了 1000 sat，则该染色币的最小分裂单位为 1 sat。这意味着该资产或代币可以被切分或分配为最多 1000 份（但是仅为理论上的，为了防止粉尘攻击，比如当年的 sat 都定在 546 SAT，后面到 ordinal 则是更高）。

验证问题

为了确定染色币的真实性和其所有权，需要从该资产的创世交易追踪验证到当前的 UTXO。因此需要专门开发钱包与配套的全节点，甚至是浏览器。

潜在的矿工审查风险

因为 ColoredTransaction 的特征较为明显，即在 output 中写入了 metadata 信息，这给矿工审查带来了可能性。

染色币实际上是一种资产跟踪系统，它使用比特币的验证规则来追踪资产转移。不过，为了证明任何特定的输出（txout）代表某一特定资产，需要提供一整条从资产起源到现在的转移链。这意味着验证某笔交易的合法性可能需要很长的证明链。为了解决这个问题当初也是有人提出了OP_CHECKCOLORVERIFY来帮助在 btc 上直接对 Colored Coins 的交易正确性进行验证，但是该提案也并没有通过。

加密行业的第一个 ICO：Mastercoin

Mastercoin 的最初概念由 J.R. Willett 提出。在 2012 年，他发布了一个名为"The Second Bitcoin Whitepaper"的白皮书，描述了在比特币的现有区块链上创建新的资产或代币的概念，这后来被称为“MasterCoin”。而再后来则改名为 Omni Layer。

Mastercoin 项目在 2013 年进行了一个初步的代币销售（今天我们称之为 ICO 或初始代币销售），并成功筹集了数百万美元，这被认为是历史上第一个 ICO。Mastercoin 最著名的应用则是 Tether (USDT)，作为最知名的法币稳定币，最初是在 Omni Layer 上发行的。

其实 Mastercoin 的想法是要比 Colored Coins 出现得要早的，之所以在这里放在第二个去讲，是因为相对于 Colored Coins 来说，MasterCoin 是一个相对来说更重的方案。MasterCoin 建立了一个完整的节点层，从而提供了更为复杂的功能（如智能合约），Colored Coins 则更加简单和直接，主要侧重于“染色”或标记比特币 UTXO，以代表其他资产。

与 Colored Coins 最大的不同是，在链上 Mastercoin 只会去发布各种类型的交易行为，而不会记录相关的资产信息。在 Mastercoin 的节点中，会通过扫描比特币区块来维护一个状态模型的数据库在链下的节点中。

相对于 Colored Coins 来说，其能完成的逻辑要更加复杂。并且由于不在链上记录状态和进行验证，所以其交易之间可以不要求连续（持续染色）。

但为了实现 Mastercoin 的复杂逻辑，用户需要去相信节点中的链下数据库中的状态，或者自己允许 Omni Layer 节点来进行验证。

Mastercoin 总结

Mastercoin 与 Colored Coins 最大的差异在于，其没有选择在链上维护协议所需的所有数据，而是通过寄生了 BTC 的共识系统，来实现了自己交易发布和排序，然后在链下数据库中维护状态。

据 OmniBolt 的相关提供的消息：Omni Layer 正在向泰达提出新 UBA(UTXO Based Asset) 资产协议，会利用 Taproot 升级，把资产信息编入 tapleaf，从而做到条件支付等功能。与此同时 OmniBolt 正在将 Stark 引入 OmniLayer 的闪电网络设施。

客户端验证 (Client Side Validation) 思想

如果我们要去了解客户端验证的概念，那么我们就要把时间拉回到 Colored Coins 和 Mastercoin 出现的第二年，那便是 2013 年。Peter Todd 在这一年发布文章：Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation。虽然看文章名字上去和客户端验证没有关系，但是仔细阅读便可以发现这便是最早关于客户端验证的启蒙思想。

Peter Todd 是比特币和密码学的早期研究者，一直在寻找一种使比特币工作方式更高效的方法。他基于时间戳的概念开发了一个更为复杂的客户端验证概念。此外，他还提出了“single use seal”的概念，这将在后面有所提及。

现在让我们顺着 Peter Todd 的思想，先要去了解 BTC 实际上解决了什么样的问题。在 Peter todd 看起来 BTC 总共解决了三个问题：

• 证明的发布（Proof-of-publication）: 证明的发布本质是解决双花问题，比如 Alice 有一些比特币想要转给 Bob，虽然通过签署了一笔交易转账给了 Bob，所以 Bob 在物理上并不一定知道有这么一笔转账的存在。所以我们需要一个公共的地方进行交易的发布，并且每个人可以从中对交易进行查询。
• 交易定序（Order consensus）：在计算机系统，并不存在我们平常感受的物理时间。在分布式系统这个时间通常是分布式时钟 lamport，这个时钟并不是为我们的物理时间提供度量，而是为我们的交易进行定序。
• 交易验证（Validation）（可选项）：BTC 上的验证便是关于签名和 BTC 转账金额的验证。但是在这里，Peter Todd 认为这个验证对于在 BTC 之上构建一个代币系统是非必要的，只是一个优化选项。

大家看到这里其实已经想到之前提到的 Ominilayer，OminiLayer 本身并没有把状态的计算和验证交给 BTC，但是它同样复用了 BTC 安全性。Colored Coins 则是把状态的追踪交给了 BTC。这两者的存在已经证明了验证并不一定要发生在链上。

那么客户端验证如何有效验证交易？

首先来看看哪些东西是需要被验证的：

• 状态（交易逻辑验证）
• 输入 TxIn 是否有效（防止双花）

很容易可以发现在 btc 上发布的资产，每次交易都需要校验整个相关的交易的历史，才能确保引用的输入是没有被消费并且状态是正确的。这非常不合理，那么如何去改进呢？

Peter Todd 认为，我们可以通过改变验证的焦点来简化这一过程。而不是确认一个输出没有被双重支出，这个方法重点放在了确认交易的输入已被发布，并且没有与其他输入冲突。通过对每个区块中的输入进行排序和使用 Merkle 树，可以更高效地进行这种验证，因为每次验证都只需要一小部分的数据，而不是该输入的整个链上的历史。

Peter Todd 提出的 commitment tree 结构如下：

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn

但是我们该如何在链上存储这样一个 commitment tree 呢？所以在这里我们就可以引出一次性密封（single use seal）的概念了。

一次性密封 Single Use Seal

Single use seal 是理解客户端验证的核心概念之一，这与实际世界中用于保护货运集装箱的物理、单次使用的密封相类似。Single use seal 是一个独特的对象，可以确切地在一个消息上关闭一次。简言之，一次性密封是一个抽象的机制，用于防止双花。

对 SealProtocol 来说，有三个要素，两个动作。 基础要素：

• l：seal, 即是密封
• m：message, 消息
• w：witness, 见证人

基本操作：有两个基础操作：

• Close(l,m) → w：在消息 m 上关闭密封 l，产生一个见证人 w。
• Verify(l,w,m) → bool：验证密封 l 是否在消息 m 上被关闭。

single use seal 的实现在安全性方面是无法被攻击者找到两个不同的消息 m1 和 m2，并使得 Verify 函数对同一个密封返回 true 的。

首先一次性密封（Single-Use Seal）是一个概念，它确保某种资产或数据只被使用或锁定一次。在比特币的环境中，这通常意味着一个 UTXO（未使用的交易输出）只能被消费一次。因此，比特币交易的输出可以被看作是一次性密封，而当这个输出被用作另一个交易的输入时，该密封就被“打破”或“使用”了。

对于在 BTC 上的 CSV 资产来说，比特币自己就充当了一次性密封的“见证人”（witness）。这是因为，为了验证一个比特币交易，节点必须检查交易的每个输入是否引用了一个有效且尚未花费的 UTXO。如果一个交易试图双重花费一个已经被使用的 UTXO，那么比特币的共识规则和全网的诚实节点会拒绝该交易。

能不能再简单一点？

single use seal 就是把任意一个区块链当作一个数据库，我们将某个消息的承诺通过某种方式存入这个数据库里，并且为它维护一个已消费或者待消费的状态。

是的，就是这么简单。

综上所述，客户端验证的资产有以下特点：

• 链下数据存储：客户端验证的资产其交易历史、所有权和其他相关数据大多数都存储在链下。这大大减少了链上的数据存储需求，并有助于提高隐私。
• 承诺机制：虽然资产数据存储在链外，但对这些数据的更改或转移会通过承诺（commitments）被记录到链上。这些承诺使得链上的交易能够引用链外的状态，从而确保链外数据的完整性和不可篡改性。
• 链上见证者（不一定是 BTC）：虽然大部分数据和验证都在链外，但通过嵌入到链上的承诺，客户端验证的资产仍然可以利用基础链的安全性（证明的发布，交易的排序）。
• 验证工作在客户端完成：大部分验证工作都在用户设备上完成。这意味着不需要全网节点都参与验证每笔交易，只有涉及到的参与者需要验证交易的有效性。

对于使用客户端验证资产的人来说，还会有一点需要注意：在链下交易和验证客户端验证的资产的时候，不仅要出示持有资产的私钥，也要同时出示对应资产的完整的 merkel 路径的证明。

客户端验证（CSV）的先行者：RGB

RGB 的概念在 2015 后由社区中的知名人物 Giacomo Zucco 提出，由于以太坊的兴起和 ICO 开始泛滥，以及在 ICO 之前，许多人都尝试在比特币之外做一些事情，如 Mastercoin 和 Colored Coins 项目。

Giacomo Zucco 对此表示失望。他认为这些项目都不如比特币，并且他认为之前在比特币上实现代币的方式都不恰当。在此过程中，他遇到了 Peter Todd，对 Peter todd 在客户端验证 (Client-Side-Validation) 的想法开始着迷。便开始提出了RGB的想法。

RGB 同此前的资产协议的最大的区别除了之前提到的客户端验证资产的那些特点，还增加了执行的 VM 来进行图灵完备的合约执行引擎。此外为了保证合约数据的安全性，还设计了 Schema 和 Interface。Schema 和以太坊的比较相似，声明合约的内容和功能，而 Interface 则负责具体功能的实现，与编程语言中的 interface 一样。

这些合约的 schema 负责在 vm 执行的时候限制没有超出预期的行为，比如 RGB20 和 RGB21，分别负责同质化代币和非同质化代币在交易上的一些限制。

RGB 的承诺机制 PerdersenHash

从承诺机制来看，RGB 采用了 Perdersen 哈希。它的优点在于可以承诺某个值而不用披露它。将 Pedersen 哈希用于构建 Merkle 树意味着你可以创建一个隐私保护的 Merkle 树，它可以隐藏其中的值。这种结构可用于某些特定的隐私保护协议中，如一些匿名加密货币项目。但是也许并不适用于 CSV 资产，在后面和 Taproot Assets 的对比里会提到。

RGB 的虚拟机设计 Simplicity → AluVM

RGB 的目标不仅在于实现一个客户端验证的资产协议，更在于在扩展到图灵完备的虚拟机执行和合约编程进行扩展。在早期的 RGB 的设计中，它声称自己是用一个叫 Simplicity 的编程语言，该语言的特点是在执行表达式的时候会产生一个执行证明，并且能对其编写的合约更容易去做形式化验证（避免产生 bug）。但是该语言的开发并不理想，最后陷入了困境。这最后直接导致了当年 RGB 整个协议难产。最后 RGB 开始使用一个叫 AluVM，由 Maxim 开发的 VM，目标是避免任何未定义的行为，这和最初的 Simplicity 类似。新的 AluVM 据称在未来会使用一门叫 Contractum 的编程语言来替换当下使用的 Rust。

RGB layer2 扩容方向：闪电网络还是侧链？

客户端验证资产没有办法在链下保证安全的情况下连续交易的。因为客户端验证的资产还是依赖 L1 去进行交易发布和定序，所以在没有 L2 扩容方案的时候，其交易速度还是会受到其 L1 见证者的出块速度限制。这代表如果直接在比特币上进行 RGB 的交易，在严格的安全要求下，两笔相关的交易的时间需要最长间隔十分钟（BTC 的出块时间）。毫无疑问，在大部分的时候这样的交易速度是难以接受的。

RGB 与闪电网络

闪电网络的原理简单来说，就是交易的双方之间会在链下签一堆合同（承诺交易），用于保证交易双方中任何一方在违背合同的情况下，被侵害的一方能够把合同（承诺交易）递交到 BTC 进行结算，取回自己的资金并惩罚对方。也就是说闪电网络是通过协议和博弈的设计，保证在链下交易的安全性。

RGB 可以通过设计适用于 RGB 自己的支付通道合同细则来构建自己的闪电网络设施，但闪电网络的复杂度极高，构建这套设施并不是容易的事。但相对于 Lightnling labs 已经在这个领域的多年耕耘，并且 LND 在市场上有着超过 90% 的占有率。

RGB 的侧链 Prime

LNP-BP 作为当下 RGB 协议的维护者，Maxim 在 2023 年 6 月发布了一篇提案叫 Prime 的客户端验证资产扩容方案，并在其中批评了现有的侧链和闪电网络扩容方案在开发方面太复杂。Maxim表示他认为除了 Prime 以外的扩展方式还有 NUCLEUS 多节点闪电通道和 Ark/Enigma 通道工厂，这两个方案都需要开发两年以上。但是 Prime 仅需要一年便可以完成。

Prime 并非传统意义上的区块链设计，而是一个为客户端验证设计的模块化证明发布层，其由四个部分组成：

1. 时间戳服务 最快 10 秒最终确定一个交易序列。
2. 证明 通过 PMT 形式存储与区块头一同生产和发布。
3. 一次性密封 抽象的一次性密封协议，保证防双花即可。在比特币上实现，则是可以绑定到 UTXO，与当下 RGB 设计类似。
4. 智能合约协议 分片合约-RGB（可替换）

从中其实可以看到，为了解决 RGB 交易确认时间的问题，Prime 采用了一个时间戳服务来快速将链下的交易确认，并且将交易和 ID 装入区块中。并且于此同时可以把 prime 上的交易证明进一步通过 PMT 合并后再以类似 checkpoint 的方式锚定上 BTC。

基于 Taproot 的 CSV 资产协议：Taproot Assets

Taproot Assets 是基于 Taproot 的 CSV 资产协议，用于在比特币区块链上发行客户端验证的资产，这些资产可以通过闪电网络进行即时、大容量、低费用的交易。Taproot Assets 的核心是利用比特币网络的安全性和稳定性以及闪电网络的速度、可扩展性和低费用。该协议是由 Lightnling labs 的 CTO roasbeef 设计并开发，roasbeef 可能是这个星球上唯一亲自主导过比特币客户端（BTCD）和闪电网络客户端（LND）的比特币研发，对 BTC 的理解极深。

Taproot 交易只携带了资产脚本的根哈希，使得外部观察者难以辨识是否涉及 Taproot Assets，因为哈希本身是通用的，能代表任意数据。随着 Taproot 升级，比特币获得了智能合约（TapScript）的能力。在此基础上，Taproot Assets 的资产编码相当于创建了一个与 ERC20 或 ERC721 相似的代币定义。这样，比特币不仅拥有了资产定义的功能，还具备了智能合约的编写能力，从而为比特币打下了代币智能合约基础架构的雏形。

Taproot Assets 编码结构如下：

图片来自 Lightning Labs CTO roasbeef

同样作为 CSV 资产协议，Taproot Assets 相对于 RGB 的设计更加简洁。并且最大利用了当下 BTC 生态的进展，比如 Taproot 升级，PSBT 等。Taproot Assets 在应用扩展性上同 RGB 最大的差异在于执行 VM，Taproot Assets 使用的是和 BTC 原生默认相同的 TaprootScriptVM。近些年许多针对 BTC 的基础设施研究都是基于 TapScript 进行的，但受限于 BTC 的升级缓慢在短时间内得不到应用，可预见 Taproot Assets 未来会是这些新鲜想法的试验田。

Taproot Assets 和 RGB 的差异在哪里？

1. 交易的校验与轻节点友好性

Taproot Assets 由于 sum tree 的实现，验证效率和安全性高（仅通过持有证明便可以进行验证状态和进行交易，不需要遍历输入所有的交易历史）。RGB 使用的 pedersen 承诺导致其无法有效去验证输入的有效性，导致 RGB 需要回溯输入的交易历史，交易衍生到后期将会是一个非常沉重的负担。Merkel sum 的设计，也让 Taproot Assets 轻松实现了轻节点验证，这相对于以往在 BTC 之上的资产协议都不存在的。

2. 执行 VM

Taproot Assets 是顺应 Taproot 升级而生，其使用的 TaprootScriptVM 是比特币在 Taproot 升级后自带的脚本执行引擎，并且使用的 vPSBT 是 BTC 的 PSBT 的翻版，这代表一旦 Taproot Assets 的闪电通道机制开发完成，可以立刻复用所有当前 LND 的基础设施，还有以往 Lightning labs 的产品（LND 在闪电网络目前的占有率在 90% 以上）。并且最近火热的 BitVM 提案都是基于 TaprootScript 的，理论上所有的这些改进最后都可以助力 Taproot Assets。

但是对于 RGB 而言它的 VM 还有验证规则 (SCHEMA) 都是自成体系的，从某种程度上是一个相对封闭的小生态。基于 RGB 的构建只能在自己的生态里运转，其和比特币生态的关系都不如大家想象那般紧密。以 Taproot 升级的跟进举例，RGB 和 Taproot 升级唯一的关系便是把链上承诺数据编码到 Witness 的 TapLeaf 中。

3. 智能合约

当下 RGB 的实现设计里，合约和 VM 是一个被浓墨重彩的部分。但是在 Taproot Assets 中，暂时没有看到智能合约的身影。不过当下 RGB 在当下 Global State 的修改如何跟各个独立合约分片 (UTXO) 进行同步还没解释。且 Pedersen 承诺只能对资产总数进行保证，对于别的状态如何保证篡改被识别，目前看起来也没有更多解释。而对于 Taproot Assets 来讲，虽然设计简洁，但目前对于状态的存储也仅有资产余额，并没有更多状态，暂无法谈智能合约。不过据 Lightning Labs 透露，明年 Taproot Assets 将会在智能合约设计上发力。

4. 同步中心

从之前提到的在客户端验证的资产的基本原则中可以了解到，持有 Proof 和持有私钥同样重要，但是 Proof 一直在用户客户端则可能会是容易丢失的，那又该怎么办呢？在 Taproot Assets 中，我们可以通过 universe 来避免这样的问题。Universe 是一个公开可审计的稀疏 Merkle shu，覆盖一个或多个资产。与普通的 Taproot 资产树不同，Universe 不用来托管 Taproot 资产。相反，Universe 承诺了一个或多个资产历史的子集。

在 RGB 之中负责这个部分的则是 Storm，会把链下的证明数据通过 p2p 的方式进行同步存储，但是由于 RGB 的开发团队的历史原因，这些团队的证明格式目前都各不兼容。RGB 生态团队 DIBA 目前则是表示会开发 carbonado 来解决这个问题，不过尚不清楚进度。

1. 工程实现 Taproot Assets 所使用的所有 lib 都是久经考验的，因为 Lightning labs 有自己的比特币客户端（BTCD），闪电网络客户端（LND），以及大量 wallet lib 实现。反观 RGB 实现所用的 lib 大部分来自自己定义，从工业标准看 RGB 的实现尚处于实验室阶段。 ## 浅谈 BTC 扩容的未来 讨论到这里，大家也就发现了客户端验证的资产协议已经脱离了协议的范畴，开始迈向了计算扩容方向。

很多人都说未来比特币将作为数字黄金去存在，而由其他链去打造应用生态。但是对此，我有不同的看法。就像在 btc 论坛上很多讨论都是关于各种山寨币 (alt-coin) 和它们短暂的生命。这些山寨币的快速的消亡，让曾经围绕它们的资本和努力都化为泡沫。我们已经有了比特币这样强大的共识基础，没有必要为了应用协议去构建新的 L1。我们要做的就是如何将比特币这个最强的基础设施用好，从而构建一个更长期的去中心化的世界。

更少的链上计算，更多的链上验证

从应用设计来看，比特币很早选择了不是以链上计算为核心目标，而是以验证为主的设计哲学（Turing completeness and state for smart contract）。区块链本质是一个复制状态机，如果一个链的共识放在了链上计算，那么其实我们很难说最后让网络里所有的节点都重复这些计算是合理可扩展的做法。若是以验证为主，那么通过验证链下交易的有效性可能是最适合 BTC 扩容的方案。

验证发生在哪里？这很重要

对于在比特币之上的协议开发者而言，如何使用比特币做关键的验证，甚至说是把验证放在链下，如何设计安全方案，其实都是协议设计者自己的事情，不需要也不应该和链本身有所关联。那么如何实现验证，就会衍生出 BTC 不同的扩容方案。

那么基于验证实现的视角，我们有三个扩容的方向：

1. 验证发生在链上（OP-ZKP）：如果在 TaprootScriptVM 直接去实现 OP-ZKP，相当于让 BTC 本身加入 ZKP 验证的能力，从而再配合一些 Covenant 设计结算协议，就可以打造出能够继承 BTC 的安全性的 Zk-Rollup 扩容方案。但是不同于在以太坊上部署一个验证合约，BTC 的升级本身就缓慢，再加入这样非通用并且可能需要后续升级的 op-code 注定是艰难的。
2. 验证发生在半链上（BitVM）：BitVM 的设计注定了它不会是为了普通的交易逻辑服务，Robin linus 也表明了 BitVM 的未来是做各个 SideChain 的自由跨链市场。之所以说 BitVM 的方案是发生在半链上，是因为大部分时候这些验证计算都不会在链上发生，而是说发生在链下。但是围绕 BTC 的 Taproot 去设计的重要原因是为了在必要的时刻也能够利用 TapScriptVM 进行计算验证，这样也是为了从理论上继承 BTC 的安全性。在这个过程中也同时产生了一个验证信任链条，比如 n 个验证人里只要有一个是诚实的就行，也就是 Optimistic Rollups。BitVM 在链上的开销巨大，但是能够使用 ZK 欺诈证明进行效率提升吗？答案是否定的，因为 ZK 欺诈证明的实现是建立在链上可以进行 ZKP 的验证的基础上，这就回到了 OP-ZKP 方案的困窘。
3. 验证发生在链下（Client-Side-Validation, Lightning Network）：验证完全发生在链下，那就是之前的讨论过这些 CSV 的资产协议还有闪电网络了。在之前讨论里可以看到在 CSV 的设计里，我们没有办法完全杜绝共谋篡改的发生，我们能做的就是利用密码学和协议设计让这种恶意共谋伤害的范围在可控范围内，使得这种行为无利可图。 在链下验证的优点和缺点同样是非常明显，优点在于对链上的资源占用极少，扩容的潜力巨大。缺点则是几乎不可能去完全复用到 BTC 的安全性，这就对能进行的链下交易类型和交易方式有了极大的限制。并且链下验证也同时代表数据都在链下，由用户自行保管，这对软件执行环境安全性还有软件的稳定性上提出了更高的要求。

扩容演进的趋势

当下在以太坊流行的 Layer2 从范式上来讲，是通过 Layer1 去验证了 Layer2 的计算有效性，也就是把状态计算下推到了 Layer2，但是验证还是保留在 Layer1 之上。在未来我们可以把验证计算同样下推到链下，进一步释放当下区块链基础设施的性能。

原文以及参考链接

原文链接 ：https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/_k3vtpI7a5cQn5iISH7-riECpyudfI4BTeeeBMwNYDQ

Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/

CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/

Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf

Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html

Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/

Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/

Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d

Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225

Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20

Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769

BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from<span class="embed-responsive embed-responsive-16by9"><iframe class="embed-responsive-item" src="//www.youtube.com/embed/9fz34ef5GSk" allowfullscreen></iframe></span>

Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin

Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE

Todd, P. (2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement

Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/

Todd, P. (2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals

Todd, P. (2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication

Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

Linux Foundation. (2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59

Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/

Linux Foundation. (2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html

Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi

Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/

Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042

Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/

Todd, P. (2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining