通过前面两篇科普文章《RGB++科普：RGB & RGB++是什么？》《RGB，RGB+，UTXO stack，Nervos， CKB 之间的关系》（文章后面有链接），我们能够大致了解RGB是一个什么样的协议。
本文将要了解的内容包括RGB的设计原理，这样设计的背后有什么样的思考，它跟现有的类似方案进行对比具有哪些优缺点，存在哪些难以解决的问题，以及RGB++是从什么样的角度入手来解决RGB存在的问题。

所以本文的内容主要包括

第一、RGB协议的原理；
第二、RGB设计背后的思想基础；
第三、RGB跟现有类似方案对比具有哪些优缺点；
第四、RGB存在哪些难以解决的问题；
第五、RGB++解决RGB难题的思路和角度。

下面进入正文

主题1. RGB协议原理总结

RGB协议的原理是以链上痕迹最小化的方案实现对比特币网络的扩展，根据比特币链上资源紧张，计算能力差，不能验证非比特币交易的特性，RGB都做了针对性的设计。

具体来说有这样一些设计

1）定义了交易

RGB的转账和交易就是智能合约状态的转换。

比如一笔转账的结果是装有10块钱的UTXO1被花了，变成装了6块钱的UTXO2和装了4块钱的UTXO3；这个过程就是合约从状态1转换到状态2，其中合约1的状态是10块钱所有权在UTXO1里面；合约2的状态是6块钱在UTXO2里面，4块钱在UTXO3里面。UTXO里面的资金金额和位置发生了变化，实质是这10块钱的所有权发生了变化。

因此RGB的智能合约表达的就是资产的所有权发生了什么的变化，以及目前所处的状态。

2）设计了RGB协议的智能合约

合约构成分为三个部分，包括合约的起始状态，最新状态（或者当前状态）以及状态转换。起始状态定义了合约的基本属性和规则，当前状态定义的是合约最新的状态，状态转换定义的就是状态之间的转换规则。

3）把交易的过程做了拆分

并按照耗费比特币链上资源多少，在链上留下痕迹多少进行分类。把其中最复杂，最耗费资源的部分都放在链下处理，比如交易的构建，数据的计算，交易历史和状态的验证，交易的确认等等，让这些过程在P2P即点对点的场景下，通过客户端来完成；

剩下交易结算这个环节，此外还有一个环节，是在链下处理完并促使交易或者合约状态发生了转换的过程和步骤等信息，需要留下一个证据或者承诺，避免交易任何一方修改这些交易信息或者数据，这个证据就是把这些数据计算出哈希值。

RGB把这两个环节放到一起来处理，因为交易结算需要发起一笔比特币链上的交易，而链下交易处理过程的证据也需要保存到链上，因此它就把这个哈希值形式（确切的说是一个哈希树，我们就以哈希值来理解）的证据或承诺写进了这一笔交易的输出里面。这是一个特殊的输出，叫做OP_RETURN，OP_RETURN是一个无法花费的输出，因此不能叫做UTXO，它在这里的用途只是用来保存RGB链下交易的承诺或者证据。

4）一次性密封和客户端验证的独特设计

一次性密封解决了资产所有权不能被转移两次，即资产不能双花的问题；

为了实现由比特币UTXO来触发或者控制RGB资产转移的目的，RGB设计了在比特币UTXO里面封装RGB资产所有权的方案，采取的手段是将RGB链下交易的每一个UTXO都锚定到一个比特币链上的UTXO，即在RGB UTXO的锁定脚本中，将花费条件设定成指定的比特币UTXO。
这个设定决定了这笔RGB资产的解锁只有一个途径：必须使用指定的比特币UTXO经过密码学计算获得的值，与锁定脚本里面的值进行对比，如果匹配这笔资产就能解锁，不匹配则无法花费这笔资产。
这个设计叫做一次性密封，意思是比特币的UTXO里面密封了RGB资产的所有权，由UTXO只能花费一次的特性保障了RGB资产不能被双花。

客户端验证解决了转移资产的交易有效性验证问题。

但是比特币链上的交易，通过花费一笔比特币的UTXO只能触发链下的RGB资产转移，却无法保证这笔RGB转账交易一定是有效的，比如转账金额是否正确，资金所有权是否真属于付款人，有没有伪造资金等等，因为比特币链上的交易没有验证非比特币交易的能力。为了实现这个目的RGB设计了客户端验证的方案。

客户端验证可行性的依据是比特币的UTXO记账模型，这个模型中资产都包含在UTXO里面，因此要验证一笔资产的当前状态也就是它的可用金额和所有权归属，只需要计算和验证跟这笔UTXO来源相关的所有UTXO。
又因为比特币记账模型中，每一个UTXO里面的金额实际上都有记录来源和去向，从哪个交易的哪个输入中来，又去到了哪个交易的哪几个输出，因此只要顺着这个UTXO的来源一直往前追溯到铸币交易中，把有关系的UTXO进出金额分别进行累加，然后再相减得到的差就是当前UTXO的金额，或者这笔资产的状态。

因此要验证一笔RGB资产的状态需要验证两个部分，一个是比特币链上的交易，一个是RGB链下的交易。
比特币链上验证的内容包含这样三个部分：所有跟这笔交易相关的交易，交易所在区块头的默克尔证据，以及这些交易记录的RGB交易承诺；RGB客户端只需要验证前面两个以及当前的这笔交易。
验证的时候用户可以使用比特币的轻客户端验证比特币交易的部分，使用RGB协议的客户端验证RGB交易的部分。

5）自主验证的信任基础

这其中，智能合约中代码和逻辑的执行，交易的计算，交易签名和所有权的验证，都可以由用户自主完成。这种自主验证可靠的信任假设，第一是比特币轻客户端信任比特币链上的交易都是有效的，第二，在RGB客户端，用户相信自己自己计算过一遍的交易结果。

以上是RGB协议运行的基本原理。

主题2. RGB提出的背景

RGB这个方案的核心理念是尽可能的减少对比特币主链的使用，只有在非用不可的情况下才会发起比特币链上的交易，或者向比特币区块内写入数据。
所以它对比特币链的使用就两个目的：通过花费UTXO触发RGB的交易并转移RGB资产所有权；把这笔交易的承诺写入到比特币链上。它把这两个目的合在一起只用了一笔比特币交易实现，只在一个交易输出里面写入了一个数据。

为什么RGB会有这样的一种设计理念，当时的背景是怎样的呢？

以下对RGB背景介绍的这部分内容来自BTCStudy阿剑老师的一次播客：

RGB基础的基础概念是客户端验证和一次性密封，这两个概念是在2016年由Peter Todd在一篇论文里面提出来的。这件事其实也与Vatalik有关，因为当时他是比特币杂志的记者，他对早期在比特币链上发行资产的一些协议，包括OnmiLayer，counterparty 以及其他的类似协议都做了一些研究，然后得出一个结论：如果我们想要让比特币的用户使用一些另类资产，采用比特币本身的脚本是没法办到的，因此只能使用额外的协议来发行这些资产。他的下一步计划就是创建一个在链上可以发行任意代币的协议，于是他就创建了以太坊。

那时也有另外一些人，他们也知道Vatalik的想法是对的，因为他们也很了解这些在比特币链上发行资产的早期协议。但是他们的想法则不一样：如果比特币的用户想要去使用一些其他功能，难到真的要在比特币链上去做这件事，一定要在比特币链上去写入数据，或者给它增加一些功能，让比特币本身去发行资产吗？

实际上所有这些功能的核心就是要在比特币的脚本里面塞入更多的数据然后让它去解读这些数据的含义，如果一定要在主网上去做这些事情的话，那就是每一个节点都要去解读并且验证你塞入的数据。他们认为这件事情是不成立的，也不应该这么做。

Peter Todd 甚至还有一个更加激进的观点，他说矿工其实根本都不需要知道一笔交易里面到底是什么，如果他知道了，就会有交易被矿工审查的可能性。所以矿工需要做的就是去挖矿就行了，而不应该对交易施加任何的干涉。

RGB就是在这个思想的基础之上产生的。

主题3. RGB方案与现有方案的对比

第一、跟铭文协议进行对比

1）在实现方式上

铭文是把一笔资产的信息，比如协议名称，操作指令，资产名称，交易数量等封装在一个文件里面，然后通过发起一笔比特币交易，把这些数据记录到交易脚本的某个字段，比如BRC20/ORC20/ARC20是记录在交易输入的隔离见证字段，SRC20是记录在交易输出即UTXO的多签地址里面，Runes 符文是记录在OP_RETURN的特殊输出里面。

我根据比特币交易的数据记录做了一张表，见下图。可以看到铭文铭刻的内容在比特币交易数据中的位置。比特币交易会执行的数据我用红色做了标记，铭文铭刻的内容都是放在不会被执行的位置。

他们记录的方式和空间位置可能会有一些细微的差别，但是有一个重要的相同之处，都是先上链，后验证，或者说把交易内容和过程放在比特币链上，交易发生之后在链下做有效性验证。

而RGB在实现方式上则是先验证，后上链，把交易除了结算的整个过程都放在链下，处理和验证完了才上链结算。

2）资产发行&交易合约

（1）合约形式：

RGB：点对点，只在交易方之间可见
铭文：合约内容公开上链

（2）合约规则：

RGB和铭文合约的状态转换都是通过花费比特币的UTXO来实现，以此也实现了资产所有权的转移。
但是RGB合约状态转换过程发生在链下，包括合约代码执行，交易计算，交易验证，验证通过后再上链；
铭文是先把内容上链，之后再验证。

（3）合约执行：

RGB的合约是通过RGB的客户端程序自动执行，状态转换必须通过RGB UTXO脚本中的密码机制，包括锁定脚本和解锁解锁的匹配性验证，受密码机制保证，信任来源于数学和密码学机制。
铭文的交易合约放在比特币链上，但不经过比特币执行，也不经过铭文程序的自动执行。
铭文没有自动执行合约能力这一点我没有详细研究过，是根据逻辑推出来的，我的理解是如果有经过链下程序自动执行，那么就应该会有一套铭文可以自动记账和验证的账本，而不需要索引器这一类第三方索引，记账和验证的机制；第二个逻辑是如果铭文有可以自动执行计算和验证的程序，那么它就具有智能合约的功能，那么在这个基础上发展出超越meme和交易转账唯一功能的应用就不是问题，但事实上铭文除了发行资产就没有其他应用，可能Atomicals协议有在这方面努力，但目前应该还没有实现；还有一个逻辑是合约是放在比特币链上的，链下的协议要去执行比特币链上的合约，应该没有可能性。

（4）交易数据：

RGB交易过程发生在链下，资产和合约状态都保存在链下；
铭文交易过程发生在链上，资产信息数据记录在链上，账本数据在链下。

（5）记账模式：

RGB交易记账模式跟比特币一样，也是UTXO结构，通过RGB程序处理交易自动生成账本，因此账本状态是确定的。账本由客户端程序自动生成记录，验证状态并保管数据和状态，不上链。

铭文交易通过比特币链上完成，但是比特币不会处理铭文交易，也不会为其生成账本，因此铭文记账是在链下通过Indexer进行，BRC20，ORC20，还有SRC20采用的记账模式是账本模式。
Indexer需要读取比特币链上的交易转账信息来进行记账和核对，而不是通过程序对交易代码和数据自动执行之后生成账本。
铭文记录在比特币链上的交易数据是文本数据，不是代码执行的结构化数据，因此在读取链上数据和链下记账之间存在模式转换的问题，按照不同模型进行转换，或者按照不同标准记账可能会出现账本不一致，这样就不能保证账本状态100%确定，存在最终状态对不上的可能性。

对比结论

（1）信任来源：

RGB的信任更为牢固可靠，因此相比较RGB是比铭文更为安全的资产协议。

第一RGB交易或合约状态的转换，是按照UTXO中设定的花费条件，通过密码学验证，信任来自数学，密码学和机器程序；第二RGB交易的有效性证是由用户自主验证之后才给以确认，信任来自自己；第三，RGB资产所有权的转移受到比特币UTXO的保护，信任来自比特币工作量证明机制和算力保障。

铭文的交易状态转换是通过铭文协议相关文本信息的解释，即参与者主观认为一个比特币UTXO的转移代表了某个铭文资产的转移，信任来自社会共识。

很显然，RGB协议的信任来源会比铭文的信任来源更为牢固，不管是基于数学的密码学，还是比特币算力和POW，抑或是用户的自主验证，都比社会共识产生的主观信任要可靠。因此我们可以认为RGB的交易是更为安全的模式。

（2）对智能合约的支持：

RGB支持图灵完备的智能合约，能够支持更为灵活和复杂的应用场景。

RGB的合约是自动执行，能够自主验证的智能合约；同时RGB的合约可以支持任意计算，能够实现图灵完备性；

铭文协议虽然也是一个合约，但不支持自动执行和自主验证，应该也不支持任意计算，所以不算是智能合约，更没有图灵完备能力。目前的铭文只能用于数字资产的发行和简单的转账交易，而不适合去中心化应用，和需要更广泛功能的数字资产场景。

（3）可扩展性：

RGB协议在交易速度，容量和规模方面都具有更大的优势，能够支撑的扩展能力更强。

RGB的交易发生在链下，而且在参与者之间进行，交易速度不受链上处理速度限制；交易可以多笔批量处理之后，只提交一个哈希值到链上，可以大幅度降低交易成本；交易数据记录和保存在用户自己的客户端，可以不受主链区块空间的限制；仅在参与方之间发生的交易，容量和规模都可以无限扩展；

铭文交易发生在链上，既受比特币链上区块容量限制，也受比特币出块时间限制，同时合约内容占用链上空间的大小还会影响交易的成本。这样的特性决定了铭文协议的扩展能力非常有限，对频率，数据量和处理复杂度有要求的应用在铭文协议上实现的可能性比较小。

（4）对链上资源的占用：

RGB协议对比特币链上空间的占用非常少，相比铭文对比特币网络造成的影响要小得多，是更有持续性的资产发行方式。

RGB 协议只把交易数据的哈希值放在链上，其余所有数据都在链下；

BRC-20 协议直接把操作资产交易的指令写入比特币交易和区块链上，虽然这些数据并不会被比特币所执行，但是会占用大量的区块空间，BRC20协议还会导致大量死的UTXO，造成UTXO集膨胀，给维护UTXO的全节点带来负担。
如果这种情况持续下去，最终的结果是能够承担比特币全节点所需设备和资源的节点会越来越少，比特币网络的中心化趋势就会增加。因此站在比特币整个系统的安全性这个角度，从更长远的利益来看，这种资产发行的方式，持续性是有争议的。

（5）去中心化：

RGB的去中心化程度更高，受中心化操控的程度更低，用户自主的程度更高。

RGB的合约只对交易双有效，交易也发生在参与方之间，是一种纯粹的点对点的交易，它通过把资产所有权与比特币UTXO进行绑定实现自动触发交易，通过智能合约实现了交易自动执行，通过密码学机制实现了自动验证以及验证机制的数学保障，还有所有验证都是用户自主实现，而非信任第三方的验证来确认交易。整个交易过程和机制的设计在理论上都是去中心化的。

铭文的合约是放在比特币链上的，因此合约内容是公开的。由于比特币并不执行这些合约内容，因此要获得合约状态或者资产余额，需要索引器读取数据，而目前的索引器基本上都是中心化机构在运营，也就是说铭文账本的解析和索引由中心化索引器来实现（貌似ARC20只有资产发行的记账需要索引器，转账可以通过比特币交易UTXO的转移来记账）。

从中心化这个方面来讲，是信任来源完全不同，所带来的信任度也就完全不同；从恶意行为的可能性上来讲，只要是中心化的操作，就无法完全杜绝作恶的可能性；从用户自主程度上来讲，中心化的索引器用户无法进行自主验证，对交易的结果必须信任账本和验证服务的提供者。

（6）记账模式：

RGB的UTXO记账模式可以降低验证合约状态的成本，也增加了用户验证合约的自主性。

BRC20，ORC20，还有SRC20采用的记账模式是账本模式，而非UTXO模式，这种方式记账要验证某个指定交易或者资产的状态难度比UTXO模式要难得多。

UTXO模式只需要找到跟当前资产相关的交易，计算这些交易中的资产余额即可；而账户模式需要把合约中所有账户的所有交易都找出来计算才能获得某一笔资产的当前状态，验证的成本会高很多。
这是因为账户模型中的状态是全局状态，合约的状态都是共享记录并保存的。因此这种模式下，用户想要通过自己验证难度和成本也会大很多。

总结：

第一：在对比特币能力的扩展上面，相比铭文，RGB协议在智能合约能力，对比特币网络能力和性能的扩展，资产和交易安全性保障，去中心化程度，用户参与的自主程度，以及资产和交易隐私性都比铭文要更有优势。

第二：对比特币带来的影响上面，RGB为比特币系统带来能力和性能的扩展，让比特币一层发行的RGB资产能够具有更多灵活和复杂的应用可能性，同时却并没有对比特币UTXO的结构进行任何改变，也没有在链上留下无效的UTXO，对比特币本身的影响微乎其微，因此是具有可持续性的一层资产协议。

以上是对RGB与铭文类都作为比特币一层资产协议的对比。

原文链接