链外交易：比特币资产协议的演变
前言
基于BTC发行资产一直是热门话题。从2011年最早的彩色币到最近流行的Ordinal协议，BTC社区一直能够提出新的参与者和共识，但很少有人能坚持下来。然而，闪电实验室公布了雄心勃勃的计划，即开发基于 Taproot Assets 的稳定币。 Tether 还宣布将利用 RGB 协议在比特币第一层上铸造 USDT。
这意味着曾经著名的OmniLayer（原Mastercoin）不再是BTC生态系统中最大的参与者。而客户端验证（CSV）资产协议也开始进入大家的视野。这些协议不仅保持了传统比特币资产协议的完整性，而且增强了可扩展性。然而，比特币生态系统中的一系列资产协议提出了相关问题：它们之间有何不同，以及人们应该如何在这一领域中导航和抓住机会？
本文旨在引导读者全面回顾比特币历史上出现的各种资产协议。此外，它还试图深入研究基于比特币的资产协议在可预见的未来的发展轨迹。
彩色硬币(Colored Coin)
彩色硬币的概念最初由现任eToro首席执行官Yoni Assia在2012年3月27日发表的开创性文章“比特币2.X（又名彩色比特币）”中提出。文章认为，比特币的底层技术就像互联网上的 HTTP 一样基础且完美。因此，Colored Coins 代币协议是在 BTC 之上设计的。
Yoni Assia设想通过这一创新创造BTC 2.0经济体，使任何社区都能以这种方式生成多种货币。利用比特币的底层技术进行交易结算和防止双重支付，在当时是一个开创性的想法。
彩色硬币是一种在比特币区块链上发行资产的协议。它通过“着色”比特币的特定部分来表示其他资产。这些标记的比特币仍保留其原始功能，但它们也代表另一种资产或价值。然而，紧迫的问题是，这个想法如何在比特币网络上实现。
2014年7月3日，ChromaWay取得重大进展，开发了增强彩色硬币基于订单的协议（EPOBC），极大地简化了开发人员创建彩色硬币的过程。这是首个使用比特币脚本的OP_RETURN功能的协议。
结果如下：
这种实现方式非常简洁，但它也带来了许多问题：
- 可替代性和最小绑定价值问题：通过在创世交易中绑定1000个sats的彩色币，该彩色币的最小单位变成了1个satoshi。这意味着资产或代币理论上可以被分成最多1000个单位（但实际上为了防止粉尘攻击，这个数字会更低。例如，最小的satoshi值曾被设定为546个SATs，对于Ordinals来说，这个值甚至更高）。
- 验证挑战：为了确定彩色币的真实性和所有权，需要从创世交易追溯并验证其交易历史，直至当前的UTXO。因此，需要开发专用的钱包、完整节点甚至扫描器。
- 潜在的矿工审查风险：ColoredTransaction具有独特的特征，例如在输出中编写元数据，这带来了矿工审查的可能性。
彩色币本质上是一个利用比特币验证规则来追踪资产转移的资产追踪系统。然而，为了证明任何特定的输出（txout）代表特定资产，你需要提供从资产起源开始的整个转移链。这意味着验证交易的有效性可能需要一个长的证明链。为了解决这个问题，提出了像OP_CHECKCOLORVERIFY这样的方案，以帮助直接在BTC上验证彩色币交易，但该方案并未被采纳。
加密领域的第一个 ICO：Mastercoin
Mastercoin的概念最初是由J.R. Willett提出的。2012年，他发表了一篇名为《比特币第二白皮书》的白皮书，阐述了在现有比特币区块链上创建新资产或代币的想法。这个概念最终被称为“MasterCoin”，后来更名为Omni Layer。
2013年，Mastercoin项目进行了早期版本的ICO（首次币发行），成功筹集了数百万美元。这被认为是历史上第一个ICO。Mastercoin最著名的应用之一是Tether（USDT），这是一种知名的法币抵押稳定币，最初在Omni Layer上发行。
实际上，Mastercoin的想法早于彩色币（Colored Coins）。我们之所以第二个讨论它，是因为与彩色币相比，MasterCoin是一个相对更全面的解决方案。MasterCoin建立了一个完整的节点层，提供了更复杂的功能，如智能合约。相比之下，彩色币更简单直接，主要专注于“着色”或标记比特币UTXO以代表其他资产。
两者的主要区别在于，在区块链上，Mastercoin仅记录各种类型的交易行为，不存储相关资产信息。在Mastercoin的节点中，通过扫描比特币区块来维护状态模型的数据库，这个数据库存在于区块链之外的节点中。
与彩色币相比，Mastercoin可以执行更复杂的逻辑。此外，因为它不在区块链上记录或验证状态，其交易不需要连续（连续着色）。
然而，要实现Mastercoin的复杂逻辑，用户需要信任节点内部的离线数据库中维护的状态，或运行自己的Omni Layer节点来进行验证。
总结如下：
Mastercoin与彩色币的主要区别在于，Mastercoin不在区块链上维护协议所需的所有数据。相反，它依托于比特币的共识系统来管理自己的交易发布和排序，然后在离线数据库中维护状态。
根据OmniBolt提供的信息：Omni Layer正在向Tether提议一种新的UBA（基于UTXO的资产）资产协议，该协议将利用Taproot升级。这个协议将把资产信息嵌入到tapleaf中，实现诸如条件支付等功能。与此同时，OmniBolt正在将Stark整合到Omni Layer的闪电网络基础设施中。
客户端验证的概念
客户端验证的概念
要理解客户端验证（Client Side Validation，简称CSV）的概念，我们需要回溯到彩色币（Colored Coins）和万事达币（Mastercoin）出现后的第二年，即2013年。在那一年，早期比特币和加密学研究员彼得·托德（Peter Todd）发表了一篇题为“解构加密货币挖矿：时间戳、公开证明和验证”的文章。尽管标题中没有明确提到客户端验证，但仔细阅读可以发现，这是最早介绍这一概念的文章之一。
彼得·托德一直在寻找使比特币运作更加高效的方法。他基于时间戳的概念，发展出了一个更复杂的客户端验证概念。此外，他还引入了“一次性密封”（single use seal）的概念，这将在后文中提到。
要追随彼得·托德的思路，我们首先需要理解比特币实际解决的问题。根据彼得·托德的观点，比特币解决了三个问题：
公开证明（Proof-of-publication）：公开证明的本质是解决双重支付问题。例如，如果爱丽丝想要转移一些比特币给鲍勃，尽管她已经签署了一个转移给鲍勃的交易，但鲍勃可能并不实际知道这样的交易存在。因此，我们需要一个公共场所来发布交易，每个人都可以从那里查询交易。
顺序共识（Order consensus）：在计算机系统中，我们通常经历的物理时间并不存在。在分布式系统中，时间通常是兰波特时间戳（Lamport timestamps），它们不提供我们的物理时间测量，但为我们的交易排序。
验证（可选）：在比特币上的验证涉及验证签名和BTC交易中转移的金额。然而，彼得·托德认为，在比特币之上构建代币系统时，这种验证并不是必需的，它只是一个优化选项。
至此，你可能会回想起我们之前讨论的OmniLayer。OmniLayer本身并没有将状态计算和验证委托给比特币，但它确实重用了比特币的安全性。另一方面，彩色币将状态跟踪托付给了比特币。这两个系统的存在已经证明，验证并不一定必须发生在区块链上。
如何通过客户端验证有效地验证交易呢？
首先，让我们看看需要验证什么：
状态（交易逻辑验证）
验证输入（TxIn）是否有效，以防止双重支付。
不难注意到，对于在比特币上发行的资产，每笔交易都需要验证整个相关交易历史，以确保所引用的输入没有被花费，并且状态是正确的。这是非常不切实际的。那么，我们如何改进这一点呢？
彼得·托德（Peter Todd）建议，我们可以通过改变验证的重点来简化这个过程。与其确认输出没有被双重支付，不如确保交易的输入已被发布且不与其他输入冲突。通过对每个区块中的输入进行排序并使用默克尔树，这种验证方式可以更高效地完成，因为它每次只需要一小部分数据，而不是输入的整个链历史。
彼得·托德提出的承诺树结构如下：
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn
但我们如何在区块链上存储这样的承诺树呢？这就是我们可以引入“单次使用封印”概念的地方。
单次使用封印
单次使用封印是理解CSV的核心概念之一。它类似于用于保护货柜的物理一次性封印。单次使用封印是一个独特的对象，它可以在一条消息上精确地关闭一次。简单来说，单次使用封印是一种用于防止双重支付的抽象机制。
对于SealProtocol，有三个基本元素和两个基本操作。
基本元素：
l: 封印
m: 消息，即信息或交易
w: 见证人，可以验证封印的某人或某物
基本操作：有两个基本动作：
Close(l, m) → w: 在消息m上关闭封印l，产生一个见证人w。
Verify(l, w, m) → bool: 验证封印l是否已经在消息m上关闭。
单次使用封印实现的安全性意味着攻击者无法找到两个不同的消息m1和m2，使得对于同一个封印，Verify函数返回真。
简单来说，单次使用封印确保某个资产或数据只被使用或锁定一次。在比特币的背景下，这通常意味着一个UTXO只能被消费一次。因此，比特币交易输出可以被视为单次使用封印，当一个输出在另一个交易中被用作输入时，该封印被“破坏”或“使用”。
对于比特币上的资产，比特币本身就是单次使用封印的“见证人”(w)。这是因为要验证比特币交易，节点必须检查交易的每个输入是否引用了有效且未被消费的UTXO。如果交易试图双重消费已经被使用的UTXO，比特币的共识规则和诚实节点网络将拒绝该交易。
更简单地说：
单次使用封印将任何区块链视为一个数据库，在其中我们存储对某个消息的承诺，并维护其状态为已消费或未消费。
总结以上内容，使用客户端验证的资产具有以下特点：
链下数据存储：使用客户端验证的资产的交易历史、所有权和其他相关数据主要存储在链下。这大大减少了链上数据存储的需求，并有助于提高隐私。
承诺机制：尽管资产数据存储在链下，但对这些数据的更改或转移会通过承诺在链上记录。这些承诺允许链上交易引用链下状态，确保链下数据的完整性和不可变性。
链上见证人（不一定是BTC）：尽管大部分数据和验证发生在链下，使用客户端验证的资产仍然可以通过链上嵌入的承诺，利用底层区块链的安全性（发布证明、交易排序）。
客户端完成验证工作：大部分验证工作在用户设备上完成。这意味着网络中的每个节点不需要参与验证每笔交易；只有参与方需要验证交易的有效性。
对于使用客户端验证的资产进行交易和验证时，还有一个额外的注意点：
在链下进行资产交易和验证时，不仅需要出示持有资产的私钥，还需要提供相应资产的完整Merkle路径证明。
RGB，CSV 的先驱
RGB的概念是由社区知名人士Giacomo Zucco在2015年后提出的。当时正是以太坊兴起、ICO（首次代币发行）激增、以及许多尝试创造超越比特币的项目（如Mastercoin和Colored Coins）的时期。
Giacomo Zucco对这些发展感到失望。他认为，这些项目都没有达到比特币的潜力，而且之前在比特币上实现代币的尝试是不足的。在此期间，他遇到了Peter Todd，并对Todd关于客户端验证（CSV）的想法产生了浓厚的兴趣。这促使他提出了RGB的想法。
除了前面提到的使用客户端验证的资产特性外，RGB与早期资产协议的主要区别是增加了用于图灵完备合约执行的执行虚拟机（VM）。为了确保合约数据的安全，设计了模式（Schema）和接口（Interface）。模式类似于以太坊，宣布合约的内容和功能，而接口则负责实现特定功能，类似于编程语言中的接口。
这些合约的模式负责限制在VM执行期间超出预期的行为。例如，RGB20和RGB21分别负责在交易中对可替代和不可替代代币施加某些限制。
RGB中使用的承诺机制，Pedersen Hash
其优势在于能够承诺一个值而不披露它。使用Pedersen Hash构建默克尔树意味着你可以创建一个保护隐私的默克尔树，能够隐藏其值。这种结构在某些保护隐私的协议中很有用，比如一些匿名加密货币项目。然而，它可能不适用于CSV资产，后者将与Taproot资产进行比较。
RGB 简单性虚拟机设计 → AluVM
RGB的目标不仅是实现客户端验证的资产协议，还要扩展到图灵完备的虚拟机执行和合约编程。最初，RGB声称使用一种名为简化（Simplicity）的编程语言，该语言生成执行证明，并允许对用它编写的合约进行形式验证（以避免错误）。然而，这种语言的开发并没有按计划进行，导致复杂性最终阻碍了整个RGB协议。最终，RGB开始使用Maxim开发的名为AluVM的虚拟机，目的是避免任何未定义行为，类似于原始的简化。据说新的AluVM将来会被一种名为Contractum的编程语言所取代，这种语言目前使用Rust。
RGB的第二层扩展方向：闪电网络还是侧链？
客户端验证的资产不能持续安全地离线交易，因为它们仍然依赖于L1进行交易发布和排序。这意味着没有第二层扩展解决方案，它们的交易速度仍然受到其L1见证的区块产生速度的限制。这意味着如果RGB交易直接在比特币上进行，在严格的安全要求下，两个相关交易之间的时间至少需要相隔十分钟（BTC的区块时间），这通常是不可接受的慢。
RGB 和闪电网络
简单来说，闪电网络的运作方式是让交易双方在链下签署一堆合约（承诺交易）。这些合约确保如果任何一方违反协议，受害方可以将合约（承诺交易）提交给BTC进行结算，收回其资金，并对违规者进行惩罚。换句话说，闪电网络通过协议和博弈论设计保证了链下交易的安全。
RGB可以通过设计适合RGB本身的支付通道合约细节来构建自己的闪电网络基础设施。然而，由于闪电网络的高度复杂性，建设这样的基础设施并不容易，特别是考虑到闪电实验室在该领域的多年工作以及LND超过90%的市场份额。
RGB 的侧链 Prime
RGB协议的当前维护者LNP-BP，在2023年6月发布了Maxim的一项关于客户端验证资产扩展解决方案的提案，名为Prime。其中，Maxim批评了现有的侧链和闪电网络扩展解决方案在开发上过于复杂。他表示，除了Prime，其他扩展方法，包括NUCLEUS多节点闪电通道和Ark/Enigma通道工厂，需要超过两年的开发时间。然而，Prime可以在仅一年内完成。
Prime不是设计为传统的区块链。相反，它是一个专门为客户端验证而创建的模块化证明发布层。它由四个主要组成部分构成：
- 时间戳服务：这项服务可以在短短10秒内完成一系列交易的最终确认。
- 证明：这些证明以部分默克尔树（PMTs）的形式存储，并与区块头一起产生和发布。
- 单次使用密封：这是一个抽象的单次使用密封协议，旨在防止双重支付。在比特币上实施时，它可以绑定到UTXO，类似于当前的RGB设计。
- 智能合约协议：分片合约用于RGB（可以替换）
由此可见，为了解决RGB中交易确认时间的问题，Prime利用时间戳服务快速确认链下交易，并将它们与ID一起打包成区块。同时，Prime上的交易证明可以通过PMTs进一步整合，然后以类似于检查点的方式锚定到BTC上。
基于 Taproot 的 CSV 资产协议：Taproot Assets
Taproot资产是一种基于Taproot的CSV资产协议，专为在比特币区块链上发行资产而设计。通过闪电网络，这些资产可以即时、大量且低成本地进行交易。Taproot资产的核心是利用比特币的安全性和稳定性，结合闪电网络的速度、可扩展性和低成本。该协议由闪电实验室（Lightning Labs）的首席技术官roasbeef设计和开发。Roasbeef可能是地球上唯一一个亲自领导开发了比特币客户端（BTCD）和闪电网络客户端（LND）的人，这显示了他对BTC的深刻理解。
Taproot交易只携带资产脚本的根哈希，使得外部观察者难以识别它们是否涉及Taproot资产，因为哈希本身是通用的，可以代表任何数据。随着Taproot升级，比特币获得了执行智能合约（TapScript）的能力。在此基础上，Taproot资产的资产编码本质上创建了一个类似于ERC20或ERC721的代币定义。因此，比特币不仅获得了定义资产的能力，还获得了编写智能合约的能力，为比特币打下了代币智能合约基础设施的基础。
Taproot资产的编码结构如下：
作者：Roasbeef，Lighting Labs 首席技术官
作为CSV资产协议，Taproot资产相较于RGB有更简洁的设计。在应用可扩展性方面，Taproot资产与RGB的最大区别在于执行VM，Taproot资产使用与BTC的原生默认相同的TaprootScript VM。近年来，许多关于BTC的基础设施研究都基于TapScript，但由于BTC升级缓慢，这些研究不能在短期内应用，因此可以预见，Taproot资产将成为这些新思想在未来的试验场。
Taproot Assets 与 RGB之间的差异
1. 交易验证和轻节点友好性
Taproot Assets由于采用和树的方式，验证效率高，安全性高。它允许只需拥有证明即可进行状态验证和交易，而无需遍历整个交易历史。相比之下，RGB 使用 Pedersen 承诺使得难以有效验证输入的有效性。因此，RGB 需要追溯输入的交易历史记录，随着交易时间的推移，这可能会成为一个巨大的负担。默克尔和树的设计还使 Taproot Assets 能够轻松促进轻节点验证，这是以前在比特币之上构建的资产协议中不具备的功能。
2. 执行虚拟机(VM)
Taproot Assets 是为了响应比特币网络的 Taproot 升级而开发的。它利用 TaprootScriptVM，这是 Taproot 升级后比特币附带的脚本执行引擎。而且，它使用了vPSBT，即比特币PSBT的变体，这表明一旦Taproot Assets闪电通道机制开发出来，它可以立即重用LND（Lightning Network Daemon）当前的所有基础设施，以及Lightning Labs（LND）之前的产品目前在闪电网络中占有超过90%的市场份额）。此外，最近流行的 BitVM 提案是基于 TaprootScript 的，这从理论上讲意味着所有这些改进最终都可以使 Taproot Assets 受益。
然而，RGB 的运作方式略有不同。它的虚拟机和验证规则（SCHEMA）是一个独立系统的一部分，形成了一个有点封闭的生态系统。 RGB 在自己的生态系统内运作，它与更广泛的比特币生态系统的关系并不像某些人想象的那么密切。例如，对于 Taproot 升级，RGB 唯一真正的交互是将承诺数据编码到 Witness TapLeaf 中的区块链上。这说明 RGB 和 Taproot 升级仅存在最低程度的关联。
3. 智能合约
在当前的 RGB 实现中，合约和 VM 被重点强调。然而，在 Taproot Assets 中，似乎并没有关注智能合约，至少目前还没有。当前的 RGB 实现尚未解释对全局状态的修改如何与各个合约分片 (UTXO) 同步。此外，虽然Pedersen的承诺可以确保资产总量，但不清楚其他状态如何免受篡改，因为这方面的解释不多。
另一方面，Taproot Assets 的设计更简单，但目前仅存储资产余额，不处理更复杂的状态，使得智能合约讨论还为时过早。不过，据 Lightning Labs 称，明年计划将重点放在 Taproot Assets 的智能合约设计上。
4. 同步中心
前面提到的关于资产在客户端验证的基本原则表明，拥有证明与拥有私钥一样重要。然而，由于证据保存在客户端，因此存在丢失的风险。如何解决这个问题？在 Taproot Assets 中，可以通过使用“宇宙”来避免这个问题。 Universe 是一个可公开审计的稀疏 Merkle 树，涵盖一个或多个资产。与标准 Taproot 资产树不同，Universe 不用于托管 Taproot 资产。相反，它致力于一个或多个资产历史的子集。
在 RGB 系统中，这一角色由 Storm 来完成，它通过点对点（p2p）网络同步链下证明数据。然而，由于 RGB 开发团队的历史原因，这些团队目前使用不兼容的校样格式。 RGB生态系统团队DIBA已表示将开发“卡纳多”来解决这个问题，但进展尚不清楚。
五、工程实施
Taproot Assets 使用的所有库都经过了充分测试，因为 Lightning Labs 拥有自己的比特币客户端 (BTCD)、闪电网络客户端 (LND) 和广泛的钱包库实现。相比之下，大多数用于 RGB 实现的库都是自定义的。从行业标准的角度来看，RGB的实施仍处于实验阶段。
对比特币扩容的未来简要探讨
继续讨论，显然客户端验证的资产协议已经超越了传统协议的范畴，现在正朝着计算扩容的方向发展。
许多人声称，未来比特币将作为“数字黄金”而存在，而其他区块链将创建应用生态系统。不过，我却持有不同的看法。正如比特币论坛上的许多讨论所见，有很多关于各种山寨币及其短暂寿命的讨论。这些山寨币的迅速消亡使围绕它们的资本和努力变成了泡沫。我们已经将比特币作为共识的坚实基础；无需仅为应用协议构建新的第 1 层 (L1) 解决方案。我们应该做的是利用比特币这个强大的基础设施来建立一个更长期的去中心化世界。
更少的链上计算，更多的链上验证
从应用设计的角度来看，比特币早期选择的理念不是以链上计算为中心，而是以验证为中心（智能合约的图灵完备性和状态）。区块链的本质是一个复制的状态机。如果区块链的共识侧重于链上计算，那么很难说让网络中的每个节点重复这些计算是一种合理或可扩展的方法。如果重点是验证，那么验证链下交易可能是最适合比特币可扩展性的方法。
验证在哪里进行？这一点至关重要。
对于在比特币之上创建协议的开发者来说，如何使用比特币进行关键验证，甚至将验证置于链下，以及如何设计安全方案，都是协议设计者自己的事情。它们不应该也不需要与链本身相关联。如何实现验证将导致BTC不同的扩容方案。
从基于验证的实现角度来看，我们有三个扩展方向：
1.链上验证（OP-ZKP）
直接在 TaprootScriptVM 中实现 OP-ZKP 将赋予比特币本身执行 ZKP 验证的能力。这与一些 Covenant 设计结算协议相结合，可以创建继承比特币安全性的 Zk-Rollup 扩展解决方案。然而，与在以太坊上部署验证合约不同，比特币的升级本质上很慢，添加这样一个专门的、可能需要升级的操作码必然具有挑战性。
2.半链上验证（BitVM）
BitVM的设计确保它不是用于普通交易逻辑。 Robin Linus 也表示，BitVM 的未来在于为各种侧链创建一个自由的跨链市场。 BitVM 的方法被认为是半链上的，因为大多数验证计算不会发生在链上，而是发生在链下。围绕比特币的 Taproot 进行设计的重要原因是在必要时利用 TapScriptVM 进行计算验证，理论上继承了比特币的安全性。这个过程还生成一条验证信任链，比如只需要“n”个验证者中的一个诚实验证者，这被称为乐观Rollups。
BitVM 会产生大量链上开销，但它可以使用 ZK 欺诈证明来提高效率吗？答案是否定的，因为 ZK 欺诈证明的实现依赖于在链上执行 ZKP 验证的能力，这让我们回到了 OP-ZKP 方法的困难。
3.链下验证（客户端验证、闪电网络）
完整的链下验证是指之前讨论的CSV资产协议和闪电网络。正如之前的讨论所示，我们无法完全防止 CSV 设计中的串通行为。我们能做的就是利用密码学和协议设计，将恶意串通造成的损害控制在可控范围内，使此类行为无利可图。
链下验证的优点和缺点同样明显。优点是使用最少的链上资源，并且具有巨大的可扩展性潜力。缺点是几乎不可能完全继承比特币的安全性，这极大地限制了可以进行的链下交易的类型和方式。此外，链下验证还意味着数据由用户自己保管在链下，这对软件执行环境的安全性和软件的稳定性提出了更高的要求。
扩容演变趋势
目前以太坊上流行的 Layer 2 解决方案，从范式上来说，都是通过 Layer 1 来验证 Layer 2 的计算，也就是说状态计算下推到 Layer 2，但验证仍然保留在 Layer 1。未来，我们可以类似地将验证计算推到链下，进一步释放当前区块链基础设施的性能。
声明：
- 本文转载自[mirror]，著作权归属原作者[Ben77]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。
相关文章
什么是比特币?
Gate 研究院：迷因币 (Memecoin) 板块与比特币价格的联动关系研究
链外交易：比特币资产协议的演变
前言
彩色硬币(Colored Coin)
加密领域的第一个 ICO：Mastercoin
客户端验证的概念
如何通过客户端验证有效地验证交易呢？
单次使用封印
RGB，CSV 的先驱
基于 Taproot 的 CSV 资产协议：Taproot Assets
Taproot Assets 与 RGB之间的差异
对比特币扩容的未来简要探讨
前言
基于BTC发行资产一直是热门话题。从2011年最早的彩色币到最近流行的Ordinal协议，BTC社区一直能够提出新的参与者和共识，但很少有人能坚持下来。然而，闪电实验室公布了雄心勃勃的计划，即开发基于 Taproot Assets 的稳定币。 Tether 还宣布将利用 RGB 协议在比特币第一层上铸造 USDT。
这意味着曾经著名的OmniLayer（原Mastercoin）不再是BTC生态系统中最大的参与者。而客户端验证（CSV）资产协议也开始进入大家的视野。这些协议不仅保持了传统比特币资产协议的完整性，而且增强了可扩展性。然而，比特币生态系统中的一系列资产协议提出了相关问题：它们之间有何不同，以及人们应该如何在这一领域中导航和抓住机会？
本文旨在引导读者全面回顾比特币历史上出现的各种资产协议。此外，它还试图深入研究基于比特币的资产协议在可预见的未来的发展轨迹。
彩色硬币(Colored Coin)
彩色硬币的概念最初由现任eToro首席执行官Yoni Assia在2012年3月27日发表的开创性文章“比特币2.X（又名彩色比特币）”中提出。文章认为，比特币的底层技术就像互联网上的 HTTP 一样基础且完美。因此，Colored Coins 代币协议是在 BTC 之上设计的。
Yoni Assia设想通过这一创新创造BTC 2.0经济体，使任何社区都能以这种方式生成多种货币。利用比特币的底层技术进行交易结算和防止双重支付，在当时是一个开创性的想法。
彩色硬币是一种在比特币区块链上发行资产的协议。它通过“着色”比特币的特定部分来表示其他资产。这些标记的比特币仍保留其原始功能，但它们也代表另一种资产或价值。然而，紧迫的问题是，这个想法如何在比特币网络上实现。
2014年7月3日，ChromaWay取得重大进展，开发了增强彩色硬币基于订单的协议（EPOBC），极大地简化了开发人员创建彩色硬币的过程。这是首个使用比特币脚本的OP_RETURN功能的协议。
结果如下：
这种实现方式非常简洁，但它也带来了许多问题：
- 可替代性和最小绑定价值问题：通过在创世交易中绑定1000个sats的彩色币，该彩色币的最小单位变成了1个satoshi。这意味着资产或代币理论上可以被分成最多1000个单位（但实际上为了防止粉尘攻击，这个数字会更低。例如，最小的satoshi值曾被设定为546个SATs，对于Ordinals来说，这个值甚至更高）。
- 验证挑战：为了确定彩色币的真实性和所有权，需要从创世交易追溯并验证其交易历史，直至当前的UTXO。因此，需要开发专用的钱包、完整节点甚至扫描器。
- 潜在的矿工审查风险：ColoredTransaction具有独特的特征，例如在输出中编写元数据，这带来了矿工审查的可能性。
彩色币本质上是一个利用比特币验证规则来追踪资产转移的资产追踪系统。然而，为了证明任何特定的输出（txout）代表特定资产，你需要提供从资产起源开始的整个转移链。这意味着验证交易的有效性可能需要一个长的证明链。为了解决这个问题，提出了像OP_CHECKCOLORVERIFY这样的方案，以帮助直接在BTC上验证彩色币交易，但该方案并未被采纳。
加密领域的第一个 ICO：Mastercoin
Mastercoin的概念最初是由J.R. Willett提出的。2012年，他发表了一篇名为《比特币第二白皮书》的白皮书，阐述了在现有比特币区块链上创建新资产或代币的想法。这个概念最终被称为“MasterCoin”，后来更名为Omni Layer。
2013年，Mastercoin项目进行了早期版本的ICO（首次币发行），成功筹集了数百万美元。这被认为是历史上第一个ICO。Mastercoin最著名的应用之一是Tether（USDT），这是一种知名的法币抵押稳定币，最初在Omni Layer上发行。
实际上，Mastercoin的想法早于彩色币（Colored Coins）。我们之所以第二个讨论它，是因为与彩色币相比，MasterCoin是一个相对更全面的解决方案。MasterCoin建立了一个完整的节点层，提供了更复杂的功能，如智能合约。相比之下，彩色币更简单直接，主要专注于“着色”或标记比特币UTXO以代表其他资产。
两者的主要区别在于，在区块链上，Mastercoin仅记录各种类型的交易行为，不存储相关资产信息。在Mastercoin的节点中，通过扫描比特币区块来维护状态模型的数据库，这个数据库存在于区块链之外的节点中。
与彩色币相比，Mastercoin可以执行更复杂的逻辑。此外，因为它不在区块链上记录或验证状态，其交易不需要连续（连续着色）。
然而，要实现Mastercoin的复杂逻辑，用户需要信任节点内部的离线数据库中维护的状态，或运行自己的Omni Layer节点来进行验证。
总结如下：
Mastercoin与彩色币的主要区别在于，Mastercoin不在区块链上维护协议所需的所有数据。相反，它依托于比特币的共识系统来管理自己的交易发布和排序，然后在离线数据库中维护状态。
根据OmniBolt提供的信息：Omni Layer正在向Tether提议一种新的UBA（基于UTXO的资产）资产协议，该协议将利用Taproot升级。这个协议将把资产信息嵌入到tapleaf中，实现诸如条件支付等功能。与此同时，OmniBolt正在将Stark整合到Omni Layer的闪电网络基础设施中。
客户端验证的概念
客户端验证的概念
要理解客户端验证（Client Side Validation，简称CSV）的概念，我们需要回溯到彩色币（Colored Coins）和万事达币（Mastercoin）出现后的第二年，即2013年。在那一年，早期比特币和加密学研究员彼得·托德（Peter Todd）发表了一篇题为“解构加密货币挖矿：时间戳、公开证明和验证”的文章。尽管标题中没有明确提到客户端验证，但仔细阅读可以发现，这是最早介绍这一概念的文章之一。
彼得·托德一直在寻找使比特币运作更加高效的方法。他基于时间戳的概念，发展出了一个更复杂的客户端验证概念。此外，他还引入了“一次性密封”（single use seal）的概念，这将在后文中提到。
要追随彼得·托德的思路，我们首先需要理解比特币实际解决的问题。根据彼得·托德的观点，比特币解决了三个问题：
公开证明（Proof-of-publication）：公开证明的本质是解决双重支付问题。例如，如果爱丽丝想要转移一些比特币给鲍勃，尽管她已经签署了一个转移给鲍勃的交易，但鲍勃可能并不实际知道这样的交易存在。因此，我们需要一个公共场所来发布交易，每个人都可以从那里查询交易。
顺序共识（Order consensus）：在计算机系统中，我们通常经历的物理时间并不存在。在分布式系统中，时间通常是兰波特时间戳（Lamport timestamps），它们不提供我们的物理时间测量，但为我们的交易排序。
验证（可选）：在比特币上的验证涉及验证签名和BTC交易中转移的金额。然而，彼得·托德认为，在比特币之上构建代币系统时，这种验证并不是必需的，它只是一个优化选项。
至此，你可能会回想起我们之前讨论的OmniLayer。OmniLayer本身并没有将状态计算和验证委托给比特币，但它确实重用了比特币的安全性。另一方面，彩色币将状态跟踪托付给了比特币。这两个系统的存在已经证明，验证并不一定必须发生在区块链上。
如何通过客户端验证有效地验证交易呢？
首先，让我们看看需要验证什么：
状态（交易逻辑验证）
验证输入（TxIn）是否有效，以防止双重支付。
不难注意到，对于在比特币上发行的资产，每笔交易都需要验证整个相关交易历史，以确保所引用的输入没有被花费，并且状态是正确的。这是非常不切实际的。那么，我们如何改进这一点呢？
彼得·托德（Peter Todd）建议，我们可以通过改变验证的重点来简化这个过程。与其确认输出没有被双重支付，不如确保交易的输入已被发布且不与其他输入冲突。通过对每个区块中的输入进行排序并使用默克尔树，这种验证方式可以更高效地完成，因为它每次只需要一小部分数据，而不是输入的整个链历史。
彼得·托德提出的承诺树结构如下：
CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn
但我们如何在区块链上存储这样的承诺树呢？这就是我们可以引入“单次使用封印”概念的地方。
单次使用封印
单次使用封印是理解CSV的核心概念之一。它类似于用于保护货柜的物理一次性封印。单次使用封印是一个独特的对象，它可以在一条消息上精确地关闭一次。简单来说，单次使用封印是一种用于防止双重支付的抽象机制。
对于SealProtocol，有三个基本元素和两个基本操作。
基本元素：
l: 封印
m: 消息，即信息或交易
w: 见证人，可以验证封印的某人或某物
基本操作：有两个基本动作：
Close(l, m) → w: 在消息m上关闭封印l，产生一个见证人w。
Verify(l, w, m) → bool: 验证封印l是否已经在消息m上关闭。
单次使用封印实现的安全性意味着攻击者无法找到两个不同的消息m1和m2，使得对于同一个封印，Verify函数返回真。
简单来说，单次使用封印确保某个资产或数据只被使用或锁定一次。在比特币的背景下，这通常意味着一个UTXO只能被消费一次。因此，比特币交易输出可以被视为单次使用封印，当一个输出在另一个交易中被用作输入时，该封印被“破坏”或“使用”。
对于比特币上的资产，比特币本身就是单次使用封印的“见证人”(w)。这是因为要验证比特币交易，节点必须检查交易的每个输入是否引用了有效且未被消费的UTXO。如果交易试图双重消费已经被使用的UTXO，比特币的共识规则和诚实节点网络将拒绝该交易。
更简单地说：
单次使用封印将任何区块链视为一个数据库，在其中我们存储对某个消息的承诺，并维护其状态为已消费或未消费。
总结以上内容，使用客户端验证的资产具有以下特点：
链下数据存储：使用客户端验证的资产的交易历史、所有权和其他相关数据主要存储在链下。这大大减少了链上数据存储的需求，并有助于提高隐私。
承诺机制：尽管资产数据存储在链下，但对这些数据的更改或转移会通过承诺在链上记录。这些承诺允许链上交易引用链下状态，确保链下数据的完整性和不可变性。
链上见证人（不一定是BTC）：尽管大部分数据和验证发生在链下，使用客户端验证的资产仍然可以通过链上嵌入的承诺，利用底层区块链的安全性（发布证明、交易排序）。
客户端完成验证工作：大部分验证工作在用户设备上完成。这意味着网络中的每个节点不需要参与验证每笔交易；只有参与方需要验证交易的有效性。
对于使用客户端验证的资产进行交易和验证时，还有一个额外的注意点：
在链下进行资产交易和验证时，不仅需要出示持有资产的私钥，还需要提供相应资产的完整Merkle路径证明。
RGB，CSV 的先驱
RGB的概念是由社区知名人士Giacomo Zucco在2015年后提出的。当时正是以太坊兴起、ICO（首次代币发行）激增、以及许多尝试创造超越比特币的项目（如Mastercoin和Colored Coins）的时期。
Giacomo Zucco对这些发展感到失望。他认为，这些项目都没有达到比特币的潜力，而且之前在比特币上实现代币的尝试是不足的。在此期间，他遇到了Peter Todd，并对Todd关于客户端验证（CSV）的想法产生了浓厚的兴趣。这促使他提出了RGB的想法。
除了前面提到的使用客户端验证的资产特性外，RGB与早期资产协议的主要区别是增加了用于图灵完备合约执行的执行虚拟机（VM）。为了确保合约数据的安全，设计了模式（Schema）和接口（Interface）。模式类似于以太坊，宣布合约的内容和功能，而接口则负责实现特定功能，类似于编程语言中的接口。
这些合约的模式负责限制在VM执行期间超出预期的行为。例如，RGB20和RGB21分别负责在交易中对可替代和不可替代代币施加某些限制。
RGB中使用的承诺机制，Pedersen Hash
其优势在于能够承诺一个值而不披露它。使用Pedersen Hash构建默克尔树意味着你可以创建一个保护隐私的默克尔树，能够隐藏其值。这种结构在某些保护隐私的协议中很有用，比如一些匿名加密货币项目。然而，它可能不适用于CSV资产，后者将与Taproot资产进行比较。
RGB 简单性虚拟机设计 → AluVM
RGB的目标不仅是实现客户端验证的资产协议，还要扩展到图灵完备的虚拟机执行和合约编程。最初，RGB声称使用一种名为简化（Simplicity）的编程语言，该语言生成执行证明，并允许对用它编写的合约进行形式验证（以避免错误）。然而，这种语言的开发并没有按计划进行，导致复杂性最终阻碍了整个RGB协议。最终，RGB开始使用Maxim开发的名为AluVM的虚拟机，目的是避免任何未定义行为，类似于原始的简化。据说新的AluVM将来会被一种名为Contractum的编程语言所取代，这种语言目前使用Rust。
RGB的第二层扩展方向：闪电网络还是侧链？
客户端验证的资产不能持续安全地离线交易，因为它们仍然依赖于L1进行交易发布和排序。这意味着没有第二层扩展解决方案，它们的交易速度仍然受到其L1见证的区块产生速度的限制。这意味着如果RGB交易直接在比特币上进行，在严格的安全要求下，两个相关交易之间的时间至少需要相隔十分钟（BTC的区块时间），这通常是不可接受的慢。
RGB 和闪电网络
简单来说，闪电网络的运作方式是让交易双方在链下签署一堆合约（承诺交易）。这些合约确保如果任何一方违反协议，受害方可以将合约（承诺交易）提交给BTC进行结算，收回其资金，并对违规者进行惩罚。换句话说，闪电网络通过协议和博弈论设计保证了链下交易的安全。
RGB可以通过设计适合RGB本身的支付通道合约细节来构建自己的闪电网络基础设施。然而，由于闪电网络的高度复杂性，建设这样的基础设施并不容易，特别是考虑到闪电实验室在该领域的多年工作以及LND超过90%的市场份额。
RGB 的侧链 Prime
RGB协议的当前维护者LNP-BP，在2023年6月发布了Maxim的一项关于客户端验证资产扩展解决方案的提案，名为Prime。其中，Maxim批评了现有的侧链和闪电网络扩展解决方案在开发上过于复杂。他表示，除了Prime，其他扩展方法，包括NUCLEUS多节点闪电通道和Ark/Enigma通道工厂，需要超过两年的开发时间。然而，Prime可以在仅一年内完成。
Prime不是设计为传统的区块链。相反，它是一个专门为客户端验证而创建的模块化证明发布层。它由四个主要组成部分构成：
- 时间戳服务：这项服务可以在短短10秒内完成一系列交易的最终确认。
- 证明：这些证明以部分默克尔树（PMTs）的形式存储，并与区块头一起产生和发布。
- 单次使用密封：这是一个抽象的单次使用密封协议，旨在防止双重支付。在比特币上实施时，它可以绑定到UTXO，类似于当前的RGB设计。
- 智能合约协议：分片合约用于RGB（可以替换）
由此可见，为了解决RGB中交易确认时间的问题，Prime利用时间戳服务快速确认链下交易，并将它们与ID一起打包成区块。同时，Prime上的交易证明可以通过PMTs进一步整合，然后以类似于检查点的方式锚定到BTC上。
基于 Taproot 的 CSV 资产协议：Taproot Assets
Taproot资产是一种基于Taproot的CSV资产协议，专为在比特币区块链上发行资产而设计。通过闪电网络，这些资产可以即时、大量且低成本地进行交易。Taproot资产的核心是利用比特币的安全性和稳定性，结合闪电网络的速度、可扩展性和低成本。该协议由闪电实验室（Lightning Labs）的首席技术官roasbeef设计和开发。Roasbeef可能是地球上唯一一个亲自领导开发了比特币客户端（BTCD）和闪电网络客户端（LND）的人，这显示了他对BTC的深刻理解。
Taproot交易只携带资产脚本的根哈希，使得外部观察者难以识别它们是否涉及Taproot资产，因为哈希本身是通用的，可以代表任何数据。随着Taproot升级，比特币获得了执行智能合约（TapScript）的能力。在此基础上，Taproot资产的资产编码本质上创建了一个类似于ERC20或ERC721的代币定义。因此，比特币不仅获得了定义资产的能力，还获得了编写智能合约的能力，为比特币打下了代币智能合约基础设施的基础。
Taproot资产的编码结构如下：
作者：Roasbeef，Lighting Labs 首席技术官
作为CSV资产协议，Taproot资产相较于RGB有更简洁的设计。在应用可扩展性方面，Taproot资产与RGB的最大区别在于执行VM，Taproot资产使用与BTC的原生默认相同的TaprootScript VM。近年来，许多关于BTC的基础设施研究都基于TapScript，但由于BTC升级缓慢，这些研究不能在短期内应用，因此可以预见，Taproot资产将成为这些新思想在未来的试验场。
Taproot Assets 与 RGB之间的差异
1. 交易验证和轻节点友好性
Taproot Assets由于采用和树的方式，验证效率高，安全性高。它允许只需拥有证明即可进行状态验证和交易，而无需遍历整个交易历史。相比之下，RGB 使用 Pedersen 承诺使得难以有效验证输入的有效性。因此，RGB 需要追溯输入的交易历史记录，随着交易时间的推移，这可能会成为一个巨大的负担。默克尔和树的设计还使 Taproot Assets 能够轻松促进轻节点验证，这是以前在比特币之上构建的资产协议中不具备的功能。
2. 执行虚拟机(VM)
Taproot Assets 是为了响应比特币网络的 Taproot 升级而开发的。它利用 TaprootScriptVM，这是 Taproot 升级后比特币附带的脚本执行引擎。而且，它使用了vPSBT，即比特币PSBT的变体，这表明一旦Taproot Assets闪电通道机制开发出来，它可以立即重用LND（Lightning Network Daemon）当前的所有基础设施，以及Lightning Labs（LND）之前的产品目前在闪电网络中占有超过90%的市场份额）。此外，最近流行的 BitVM 提案是基于 TaprootScript 的，这从理论上讲意味着所有这些改进最终都可以使 Taproot Assets 受益。
然而，RGB 的运作方式略有不同。它的虚拟机和验证规则（SCHEMA）是一个独立系统的一部分，形成了一个有点封闭的生态系统。 RGB 在自己的生态系统内运作，它与更广泛的比特币生态系统的关系并不像某些人想象的那么密切。例如，对于 Taproot 升级，RGB 唯一真正的交互是将承诺数据编码到 Witness TapLeaf 中的区块链上。这说明 RGB 和 Taproot 升级仅存在最低程度的关联。
3. 智能合约
在当前的 RGB 实现中，合约和 VM 被重点强调。然而，在 Taproot Assets 中，似乎并没有关注智能合约，至少目前还没有。当前的 RGB 实现尚未解释对全局状态的修改如何与各个合约分片 (UTXO) 同步。此外，虽然Pedersen的承诺可以确保资产总量，但不清楚其他状态如何免受篡改，因为这方面的解释不多。
另一方面，Taproot Assets 的设计更简单，但目前仅存储资产余额，不处理更复杂的状态，使得智能合约讨论还为时过早。不过，据 Lightning Labs 称，明年计划将重点放在 Taproot Assets 的智能合约设计上。
4. 同步中心
前面提到的关于资产在客户端验证的基本原则表明，拥有证明与拥有私钥一样重要。然而，由于证据保存在客户端，因此存在丢失的风险。如何解决这个问题？在 Taproot Assets 中，可以通过使用“宇宙”来避免这个问题。 Universe 是一个可公开审计的稀疏 Merkle 树，涵盖一个或多个资产。与标准 Taproot 资产树不同，Universe 不用于托管 Taproot 资产。相反，它致力于一个或多个资产历史的子集。
在 RGB 系统中，这一角色由 Storm 来完成，它通过点对点（p2p）网络同步链下证明数据。然而，由于 RGB 开发团队的历史原因，这些团队目前使用不兼容的校样格式。 RGB生态系统团队DIBA已表示将开发“卡纳多”来解决这个问题，但进展尚不清楚。
五、工程实施
Taproot Assets 使用的所有库都经过了充分测试，因为 Lightning Labs 拥有自己的比特币客户端 (BTCD)、闪电网络客户端 (LND) 和广泛的钱包库实现。相比之下，大多数用于 RGB 实现的库都是自定义的。从行业标准的角度来看，RGB的实施仍处于实验阶段。
对比特币扩容的未来简要探讨
继续讨论，显然客户端验证的资产协议已经超越了传统协议的范畴，现在正朝着计算扩容的方向发展。
许多人声称，未来比特币将作为“数字黄金”而存在，而其他区块链将创建应用生态系统。不过，我却持有不同的看法。正如比特币论坛上的许多讨论所见，有很多关于各种山寨币及其短暂寿命的讨论。这些山寨币的迅速消亡使围绕它们的资本和努力变成了泡沫。我们已经将比特币作为共识的坚实基础；无需仅为应用协议构建新的第 1 层 (L1) 解决方案。我们应该做的是利用比特币这个强大的基础设施来建立一个更长期的去中心化世界。
更少的链上计算，更多的链上验证
从应用设计的角度来看，比特币早期选择的理念不是以链上计算为中心，而是以验证为中心（智能合约的图灵完备性和状态）。区块链的本质是一个复制的状态机。如果区块链的共识侧重于链上计算，那么很难说让网络中的每个节点重复这些计算是一种合理或可扩展的方法。如果重点是验证，那么验证链下交易可能是最适合比特币可扩展性的方法。
验证在哪里进行？这一点至关重要。
对于在比特币之上创建协议的开发者来说，如何使用比特币进行关键验证，甚至将验证置于链下，以及如何设计安全方案，都是协议设计者自己的事情。它们不应该也不需要与链本身相关联。如何实现验证将导致BTC不同的扩容方案。
从基于验证的实现角度来看，我们有三个扩展方向：
1.链上验证（OP-ZKP）
直接在 TaprootScriptVM 中实现 OP-ZKP 将赋予比特币本身执行 ZKP 验证的能力。这与一些 Covenant 设计结算协议相结合，可以创建继承比特币安全性的 Zk-Rollup 扩展解决方案。然而，与在以太坊上部署验证合约不同，比特币的升级本质上很慢，添加这样一个专门的、可能需要升级的操作码必然具有挑战性。
2.半链上验证（BitVM）
BitVM的设计确保它不是用于普通交易逻辑。 Robin Linus 也表示，BitVM 的未来在于为各种侧链创建一个自由的跨链市场。 BitVM 的方法被认为是半链上的，因为大多数验证计算不会发生在链上，而是发生在链下。围绕比特币的 Taproot 进行设计的重要原因是在必要时利用 TapScriptVM 进行计算验证，理论上继承了比特币的安全性。这个过程还生成一条验证信任链，比如只需要“n”个验证者中的一个诚实验证者，这被称为乐观Rollups。
BitVM 会产生大量链上开销，但它可以使用 ZK 欺诈证明来提高效率吗？答案是否定的，因为 ZK 欺诈证明的实现依赖于在链上执行 ZKP 验证的能力，这让我们回到了 OP-ZKP 方法的困难。
3.链下验证（客户端验证、闪电网络）
完整的链下验证是指之前讨论的CSV资产协议和闪电网络。正如之前的讨论所示，我们无法完全防止 CSV 设计中的串通行为。我们能做的就是利用密码学和协议设计，将恶意串通造成的损害控制在可控范围内，使此类行为无利可图。
链下验证的优点和缺点同样明显。优点是使用最少的链上资源，并且具有巨大的可扩展性潜力。缺点是几乎不可能完全继承比特币的安全性，这极大地限制了可以进行的链下交易的类型和方式。此外，链下验证还意味着数据由用户自己保管在链下，这对软件执行环境的安全性和软件的稳定性提出了更高的要求。
扩容演变趋势
目前以太坊上流行的 Layer 2 解决方案，从范式上来说，都是通过 Layer 1 来验证 Layer 2 的计算，也就是说状态计算下推到 Layer 2，但验证仍然保留在 Layer 1。未来，我们可以类似地将验证计算推到链下，进一步释放当前区块链基础设施的性能。
声明：
- 本文转载自[mirror]，著作权归属原作者[Ben77]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。
相关文章
什么是比特币?