这样的实现非常简洁，但是由此也带来了很多问题：
- 同质化代币与最小绑定值
- 在创世交易中为某个染色币绑定了1000 sat，则该染色币的最小分裂单位为1 sat。这意味着该资产或代币可以被切分或分配为最多1000份（但是仅为理论上的，为了防止粉尘攻击，比如当年的sat都定在546 SAT，后面到ordinal则是更高）。
- 验证问题
- 为了确定染色币的真实性和其所有权，需要从该资产的创世交易追踪验证到当前的UTXO。因此需要专门开发钱包与配套的全节点，甚至是浏览器。
- 潜在的矿工审查风险
- 因为ColoredTransaction的特征较为明显，即在output中写入了metadata信息，这给矿工审查带来了可能性。
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与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之上构建一个代币系统是非必要的，只是一个优化选项。
- 状态（交易逻辑验证）
- 输入TxIn是否有效（防止双花）
对SealProtocol来说，有三个要素，两个动作。
基础要素：
- l： seal, 即是密封
- m： message, 消息
- w：witness, 见证人
- Close(l,m) → w：在消息m上关闭密封l，产生一个证人w。
- Verify(l,w,m) → bool：验证密封l是否在消息m上被关闭。
- 链下数据存储：客户端验证的资产其交易历史、所有权和其他相关数据大多数都存储在链下。这大大减少了链上的数据存储需求，并有助于提高隐私。
- 承诺机制：虽然资产数据存储在链外，但对这些数据的更改或转移会通过承诺（commitments）被记录到链上。这些承诺使得链上的交易能够引用链外的状态，从而确保链外数据的完整性和不可篡改性。
- 链上见证者（不一定是BTC）：虽然大部分数据和验证都在链外，但通过嵌入到链上的承诺，客户端验证的资产仍然可以利用基础链的安全性（证明的发布，交易的排序）。
- 验证工作在客户端完成：大部分验证工作都在用户设备上完成。这意味着不需要全网节点都参与验证每笔交易，只有涉及到的参与者需要验证交易的有效性。
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并非传统意义上的区块链设计，而是一个为客户端验证设计的模块化证明发布层，其由四个部分组成:
- 时间戳服务
- 最快10秒最终确定一个交易序列。
- 证明
- 通过PMT形式存储与区块头一同生产和发布。
- 一次性密封
- 抽象的单次密封协议，保证防双花即可。在比特币上实现，则是可以绑定到UTXO，与当下RGB设计类似。
- 智能合约协议
- 分片合约-RGB (可替换)
图片来自 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. 执行VMTaproot 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是一个公开可审计的（MS-SMT），覆盖一个或多个资产。与普通的Taproot资产树不同，Universe不用来托管Taproot资产。相反，Universe承诺了一个或多个资产历史的子集。
在RGB之中负责这个部分的则是Storm，会把链下的证明数据通过p2p的方式进行同步存储，但是由于RGB的开发团队的历史原因，这些团队的证明格式目前都各不兼容。RGB生态团队DIBA目前则是表示会开发 carbonado 来解决这个问题，不过尚不清楚进度。
5. 工程实现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不同的扩容方案。
那么基于验证实现的视角，我们有三个扩容的方向：
- 验证发生在链上（OP-ZKP）
- 如果在TaprootScriptVM直接去实现OP-ZKP，相当于让BTC本身加入ZKP验证的能力，从而再配合一些Covenant设计结算协议，就可以打造出能够继承BTC的安全性的Zk-Rollup扩容方案。但是不同于在以太坊上部署一个验证合约，BTC的升级本身就缓慢，再加入这样非通用并且可能需要后续升级的op-code注定是艰难的。
- 验证发生在半链上 （BitVM）
- BitVM的设计注定了它不会是为了普通的交易逻辑服务，Robin linus也表明了BitVM的未来是做各个SideChain的自由跨链市场。之所以说BitVM的方案是发生在半链上，是因为大部分时候这些验证计算都不会在链上发生，而是说发生在链下。但是围绕BTC的Taproot去设计的重要原因是为了在必要的时刻也能够利用TapScriptVM进行计算验证，这样也是为了从理论上继承BTC的安全性。在这个过程中也同时产生了一个验证信任链条，比如n个验证人里只要有一个是诚实的就行，也就是Optimistic Rollups。
- BitVM在链上的开销巨大，但是能够使用ZK欺诈证明进行效率提升吗？答案是否定的，因为ZK欺诈证明的实现是建立在链上可以进行ZKP的验证的基础上，这就回到了OP-ZKP方案的困窘。
- 验证发生在链下 （Client-Side-Validation, Lightning Network）
- 验证完全发生在链下，那就是之前的讨论过这些CSV的资产协议还有闪电网络了。在之前讨论里可以看到在CSV的设计里，我们没有办法完全杜绝共谋篡改的发生，我们能做的就是利用密码学和协议设计让这种恶意共谋伤害的范围在可控范围内，使得这种行为无利可图。
- 在链下验证的优点和缺点同样是非常明显，优点在于对链上的资源占用极少，扩容的潜力巨大。缺点则是几乎不可能去完全复用到BTC的安全性，这就对能进行的链下交易类型和交易方式有了极大的限制。并且链下验证也同时代表数据都在链下，由用户自行保管，这对软件执行环境安全性还有软件的稳定性上提出了更高的要求。
