-
-
比特币钱包官方版软件下载
- 大小：287.27 MB
- 版本：v25.0
- 语言：简体中文
- 类型：软件1
- 查看详情
本文试图对比特币上的资产发行协议RGB（也可以理解为链下智能合约系统）进行简明描述，并指出它与其他旨在实现相同目标的协议有很大不同或类似的功能。这些差异使得RGB 协议的可扩展性远远高于它们，并留下了更广阔的编程空间。除了涵盖RGB 已经完成的设计之外，我们还将探索这些编程的可能性。
在比特币上发行资产的想法由来已久。但比特币协议有自身的特性：其状态由且仅由比特币 UTXO(“未花费的交易输出”)来表达；一个 UTXO 仅携带两个数据：它自身的面额(比特币价值)，以及一个 “脚本公钥”(也称为 “锁定脚本”)，用于编程这笔资金的花费条件，例如：提供某个公钥的签名；允许用来编程锁定脚本的操作码由比特币的共识规则提供，它们不能用来实现任意的安全规则。因此，我们不可能在 UTXO 内部创造其它资产 —— 比特币脚本不能编程出这些资产的安全检查。这就意味着，所有在比特币上发行资产的想法，本质上都是对比特币区块空间的创造性使用。这意味着，我们需要设计一种链外的智能合约系统，并要求将改变合约状态的步骤 —— 例如，合约 A 改变了参数，B 将一定数量的某种资产转移给了 C —— 的信息上传到区块链，从而，可以通过收集这些信息，获得这个智能合约系统的最新状态。一个粗略的设计思路是，将改变合约状态的步骤信息原封不动地上传到比特币区块链上。这当然可以工作，但是会面临几个问题：（1）由于上传了完整的信息，当用户需要改变合约的状态（比如转账）时，可能会消耗更多的区块空间，这时候你也会需要支付更多的链上手续费。特别是，当我们希望这样的链下合约系统具有比比特币更好的可编程性时，可编程性的增加可能是以消耗更多的区块空间为代价的； (2) 区块内几乎任何一处信息都可能改变链外的智能合约。因此，用户必须获取所有比特币区块数据才能了解链下合约系统的最新状态，即其验证成本较高； （3）根据链下智能合约系统的设计，你可能只能获得与比特币相当的隐私，甚至更差；如果你能提供更多的隐私，你可能需要消耗更多的块空间。
过去，一种广泛使用的名为“Omni”的协议并不上传链下合约交易的完整信息，而只上传交易的哈希值。该方法解决了上述问题1，并将链下合约交易的复杂性与其经济成本解耦；但用户仍需要获取全量的比特币区块数据才能获取Omni协议的最新状态；此外，它并没有针对隐私进行具体的增强。
RGB 使用一种称为“一次性密封件”的新范例。它的用法非常简单：RGB要求每个合约的每个状态都必须附加到某个比特币UTXO；而一旦你想改变这个状态，你就必须花费这个UTXO，并让花费它的交易得到区块链的确认；此外，花费它的比特币交易还必须提供状态转换内容的哈希值，以指示附加到已更改状态的UTXO。
对于RGB 开发人员来说，该设计类似于带有编号的塑料封条：很容易判断它是否已被移除，而且一旦被移除，就无法重复使用。然而，另一种角度是将拥有的UTXO视为该状态下的容器或陶瓷存钱罐。 —— 如果你想取出存钱罐里的钱，你必须打破存钱罐，然后把钱放进去。放入新罐子中。
这种设计与之前将整个区块视为一块大写字板的协议形成鲜明对比：使用UTXO 作为容器意味着不花费此UTXO 的交易无法对容器中的合约状态产生任何影响。因此，要验证某个合约的某个状态，我们不需要获取所有区块的数据。我们所需要的只是一系列比特币交易，这些比特币交易存在于某个区块中的证据，以及这些比特币交易所承诺的RGB 状态转换（与相关比特币交易一对一）就足够了。这些可以连接成一条链的数据应该可以让我们追溯到这个合约的初始状态，让我们能够识别这个状态的本质。
对于熟悉链上智能合约系统（如以太坊）的读者来说，这个过程很难理解的一点是，如果它不依赖于区块链的共识（这意味着区块链的初始状态合约以及每一个状态的改变都会被各个节点验证），这个智能合约系统的安全性是如何保证的呢？如何保证你收到的资产是你想要的，如何保证资产没有被非法发行？
答案也很简单，叫做“客户端验证”—— 你自己验证一下。在链上合约系统中，节点根据公开的状态转换规则验证每个状态转换操作，拒绝无效操作，然后根据初始状态计算最新状态。不过，只要知道状态转换规则和初始状态，通过链上共识进行验证并不是唯一的方法。用户可以根据付款方提供的信息验证状态转换的每一步是否遵循最初定义的状态转换。规则。这样，验证方（假设是资产的接收方）也可以检测到非法的状态转换并拒绝接受它们。
最后我们用一个例子来演示一下RGB协议的特点：
现在，Alice 拥有UTXO A’，它持有根据RGB 协议发行的X 单位资产Y。她想将Y 的Z 个单位转移给Bob。这批资产一共经过了5位前任所有者（包括资产发行方）才到达Alice手中。因此，Alice需要向Bob提供这四种状态转换的证据（其中前三种状态转换是前任所有者提供给Alice的），包括合约的初始状态和状态转换规则，以及每次传输所使用的比特。比特币交易、每个比特币交易所提交的RGB 交易以及这些比特币交易已被某个区块确认的证据都会发送给Bob。 Bob会根据合约的状态转换规则来验证这四次转账不违反规则。然后决定是否接受。当Alice构造一笔RGB交易时，由于Z小于X，她也为自己安排了一个UTXO来接收剩下的部分。最后，Alice将此RGB交易的哈希值嵌入到花费UTXO A’的比特币交易中，完成支付。
最后，由于UTXO 容器的使用，RGB 合约的最新状态可以表示为有向无环图上没有后代的点（每个点代表存储在UTXO 容器中的状态）。而且，对于下图中的所有者P来说，他只会知道从合约的初始状态G到他的过程，也就是红圈标记的过程，而对灰色点一无所知：
如上所述，与此前在比特币上出现的资产发行协议(链外合约系统)相比，RGB 大幅降低了验证(一个合约的某一个状态)的成本。在交易的时候，接收者不再需要遍历所有区块来收集合约状态发生改变的信息，而只需获得一连串的比特币交易，以及这些交易所承诺的 RGB 交易、这些比特币交易的区块包含证据(依据区块头的默克尔证据)，就能确信支付方真的拥有一定数量的某种资产。验证成本的降低也大大降低了用户对大型基础设施提供商的依赖（信任）。在之前的协议中，由于验证成本较高，用户很难自己计算出合约的最新状态，因此用户不得不信任一些提供者（比如自己钱包使用的合约状态提供者）；同时，因为能够承担这样的成本计算的供应商较少，这也意味着供应商集中化。但在RGB中，用户可以自己负担得起，只需使用比特币轻客户端检查与比特币交易的部分，并使用RGB协议检查RGB交易部分即可。
与一些链上合约系统相比，RGB也更轻量。这体现在RGB可以专门验证合约的某种状态；在那些不基于UTXO的系统上，由于缺乏像UTXO那样控制访问的机制，任何交易都可能改变任何状态，所以你几乎不可能具体验证某个状态，而只能确定某个状态同时计算所有最新状态。 —— 从这个意义上来说，表达为“全局状态”的特性实际上应该称为“统一状态”。虽然它提供了合约之间交叉访问的特性，但也决定了它的验证成本会更高，并且更难获得去信任。
在这些链上合约协议上，一个主要的优化措施是要求区块头提交最新的状态（“状态根”），从而允许轻客户端基于从全节点获得的合约的某个状态进行验证这些承诺。这是一种复用已经发生的计算（全节点已经运行过的计算）的方法，而且效率也很高。因此，如果不考虑去信任性，可以认为比RGB更高效。但这毕竟意味着轻节点依赖于全节点进行基本的交易验证和合约状态计算。在使用比特币轻客户端的RGB钱包中，它所依赖的信任假设是相关的比特币交易是有效的交易，并且与合约状态相关的部分已经过客户端亲自验证，因此更加信任——自由的。缺点是验证延迟较长，需要保存的数据较多。
RGB 的可扩展性体现在两个方面：1. 比特币交易中嵌入的只是一个哈希值，这意味着RGB 交易量没有限制（合约自定义规则除外） —— 即使将一项RGB 资产分成100部分（RGB 交易本身会非常大）并且只有一个哈希值需要嵌入到比特币交易中。如注6所述，嵌入这样的哈希值有两种方式：一种是使用OP_RETURN输出，这意味着它会消耗哈希值的链上空间；另一种是使用OP_RETURN输出，这意味着它会消耗哈希值的链上空间。另一种是隐藏Taproot —— 输出的脚本公钥，这不会消耗已提交脚本树上的任何链上空间。这也意味着，如果仅考虑链上手续费，用户不必为了可编程性——而牺牲经济性。
2. RGB合约的最新状态是有向无环图——上没有后代的独立点。这意味着这些状态可以独立改变而不会互相影响，这意味着允许并发。这其实是继承自UTXO的一个特性。这也意味着一个分支上发生的无效变更（无效交易）不会影响其他分支，更不会导致整个合约陷入卡顿，因此也可以算是一种安全收益。
RGB的可扩展性方面受到批评的一点是，对于每一次转账，接收方都需要验证从初始状态到付款方状态所涉及的所有交易。 —— 随着资产转手次数的增加，后续接收者的验证负担将会增加。越来越重。这个批评是正确的。优化它意味着我们还需要找到一种方法来重用已经发生的操作。 SNARK 等证明系统技术有望提供这样的解决方案。
最后一个好处依然跟 UTXO 有关，取决于我们如何理解 UTXO 的锁定脚本机制。锁定脚本可用于对基金的解锁条件进行编程，从而实现托管规则。例如，如果锁定脚本包含且仅一个公钥，则意味着只有相应私钥的所有者才能控制它。然而，这样的托管规则也是比特币合约协议编程的基础。例如，使用2-of-2 多重签名锁定脚本的UTXO 可以是闪电通道；在通道过程中，双方可以几乎无限次地相互支付，而资金的链上形式几乎没有变化。也就是说，此时2-of-2多重签名锁定脚本就构成了一种价值转移机制，可以让双方在不改变链上资金形式的情况下进行价值转移。
这样的机制可以用于UTXO承载的比特币价值。自然也可以用于其携带的RGB资源。我们可以发行RGB资产并将其附加到2-of 2多重签名UTXO上，从而利用闪电通道的机制将该资产无限次地相互支付。同理，RGB资产也可以进入基于比特币脚本的其他合约中。
这里，UTXO脚本和RGB协议形成了功能区分：前者致力于实现价值托管和价值转移的规则；后者致力于实现价值托管和价值转移的规则。而后者则侧重于资产定义。这样，资产的托管和资产的定义就可以分开。这是一个重要的安全改进，也是人们在其他一些链上合约系统中努力追求的目标。
上述特性，实际上对所有基于 UTXO 一次性密封和客户端验证的协议都成立。但在此基础上，RGB 协议又做出了进一步的设计。目前RGB协议的开发中，开发者特别关心协议的隐私性，因此RGB从两个方面加强隐私性：
盲UTXO。在RGB 交易中，接收者只需使用混淆的UTXO 标识符来接收资产，而不会暴露实际接收资产的UTXO 的特征。这不会损害接收者向下一个所有者提供证据的能力，同时使后续的资产接收者能够保护自己免受前一个资产所有者的窥探。
防弹。可用于隐藏每笔交易的具体金额。不过，后续的资产所有者仍然可以验证之前没有发生过增发。
探索空间
本节我将讨论RGB协议可以继续探索的空间，主要与可编程性相关。
目前，已提出的RGB合约模板（schema）主要针对资产发行。然而，由于RGB使用“客户端验证”范例，实际上，我们可以向其添加任何可以通过客户端验证——确保的特征，仅受UTXO结构的限制。
而在 UTXO 的基础上，一个可以拓宽可编程性的概念叫做 “限制条款(covenants)” 。限制条款的本意是限制一笔资金可以转移的目的地。有了这种能力，我们就可以编程许多有趣的应用，比如：1、非互动提现资金池。我们可以将很多人的资金集中到同一个UTXO 中，并使用限制来确保他们中的任何人都可以在不需要其他人帮助的情况下提取自己的资金。当对街区空间的需求很高时，这可以帮助人们以低成本离开高风险场所。
2.安全合约。一笔资金必须先花在某个地方，并经过一个时间锁，然后才能自由花掉；在时间锁定期间，保险箱所有者可以使用紧急钥匙中断此过程，并立即将资金转移到另一个地方。该设备可以为自主监护提供很大帮助。
目前的比特币脚本不具备此功能，因此启用对比特币脚本的限制需要软分叉。
不过，只要我们愿意牺牲一些“资产定义和托管机制差异化”带来的好处，我们就可以在RGB资产上尝试这样的特性。我们可以在RGB 合约级别—— 上实现这样的功能，虽然它只能用于RGB 资产（而不是比特币），但它肯定会开辟一个有趣的空间。
现有关于限制条款的研究表明，它可以拓宽基于UTXO 的交易的编程空间并提供许多功能。但这些研究基本上都是基于比特币，对于比特币这样的协议，我们会更加保守。在RGB上，我们可以大胆地进一步概括限制条款——的核心能力，即读取在脚本级别——花费自身的交易的能力，以提供更灵活的可编程性：交叉访问合约的能力。
最小的限制条款意味着一个 UTXO 在被花费的时候，其脚本可以读取花费交易的输出。但完全泛化的限制条款则意味着：它可以读取花费它的交易的所有部分。这就意味着，它也可以读取交易的其它输入，如果我们不限定其它输入必须来自同一个合约，那就意味着，它可以读取其它合约的状态。在RGB中，我们默认每个合约都是一个独立的宇宙，拥有自己的有向无环图。然而，用户仍然有可能同时持有两个不同合约的状态。如果RGB 交易允许同时支出两个合约中的资产，那么这种交叉访问功能可能会有用例（尽管可以想象，这可能会使交易验证变得更加复杂）。
事实上，已经有基于UTXO 类似结构的链上合约系统（例如：Nervos Network），利用它来实现合约的交叉访问能力11 。这是一个非常新的领域，进入了以前的比特币研究很少触及的领域，并且那里可能埋藏着一些惊喜。
在本文中，读者会发现，有个概念被频繁提及、贯穿了推理和幻想的所有过程：“UTXO”。这正是我的用意。如果你不理解 UTXO，你就无法理解 RGB 这样的协议的设计的起点，也不能理解 RGB 协议设计的优点，也无法想象人们使用它的方式。RGB 协议的特性在很大程度上正是由其 UTXO 这种一次性密封的形式塑造的。相应地，比特币研究领域积累的对 UTXO 的研究，也可以被我们化用到对 RGB 的研究中。这也解释了为什么不懂比特币的人很难理解RGB。喜欢比特币的人一定会认可RGB 所做的设计。