├── LICENSE ├── README.md └── docs ├── assets ├── lock-verify.png ├── sa-payee.png ├── sa-pow.png ├── sa-sequencing1.png ├── sa-sequencing2.png ├── sa-time-lock.png ├── wp-binding.png ├── wp-claim.png ├── wp-dex.png ├── wp-send.png ├── wp-transfer.png ├── wp-tx-fold.png └── wp-tx-general.png ├── light-paper-cn.md ├── light-paper-en.md ├── lockscript-design-prd-cn.md ├── lockscript-design-prd-en.md ├── security-analysis-cn.md └── security-analysis-en.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2024 CELL Studio 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # RGBPlusPlus-design 2 | 3 | This repository contains the early-stage design documents for the RGB++ protocol, intended for an open discussion. 4 | 5 | Please note that these documents are preliminary and may undergo further modifications. The contents should not be considered as the final standard or implementation. 6 | 7 | **Please don't treat these documentation as the final standard or implementation.** 8 | 9 | Documents list: 10 | 11 | | # | EN | CN | 12 | | -- | -- | -- | 13 | | 00 | [RGB++ Protocol Whitepaper Draft](./docs/light-paper-en.md) | [RGB++ 协议白皮书草案](./docs/light-paper-cn.md) | 14 | | 01 | [RGB++ Script Standard](./docs/lockscript-design-prd-en.md) | [RGB++ 合约规范](./docs/lockscript-design-prd-cn.md) | 15 | | 02 | [CKB Bitcoin SPV Type Script](https://github.com/ckb-cell/ckb-bitcoin-spv-contracts/blob/master/contracts/ckb-bitcoin-spv-type-lock/README.md) | CKB BTC SPV 合约设计 | 16 | | 03 | [CKB Bitcoin SPV Library Design](https://github.com/ckb-cell/ckb-bitcoin-spv/blob/master/docs/Design.md) | CKB Bitcoin SPV 库的设计 | 17 | | 04 | [RGB++ Security Analysis](./docs/security-analysis-en.md) | [RGB++ 安全性分析](./docs/security-analysis-cn.md) | 18 | -------------------------------------------------------------------------------- /docs/assets/lock-verify.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/lock-verify.png -------------------------------------------------------------------------------- /docs/assets/sa-payee.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/sa-payee.png -------------------------------------------------------------------------------- /docs/assets/sa-pow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/sa-pow.png -------------------------------------------------------------------------------- /docs/assets/sa-sequencing1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/sa-sequencing1.png -------------------------------------------------------------------------------- /docs/assets/sa-sequencing2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/sa-sequencing2.png -------------------------------------------------------------------------------- /docs/assets/sa-time-lock.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/sa-time-lock.png -------------------------------------------------------------------------------- /docs/assets/wp-binding.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-binding.png -------------------------------------------------------------------------------- /docs/assets/wp-claim.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-claim.png -------------------------------------------------------------------------------- /docs/assets/wp-dex.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-dex.png -------------------------------------------------------------------------------- /docs/assets/wp-send.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-send.png -------------------------------------------------------------------------------- /docs/assets/wp-transfer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-transfer.png -------------------------------------------------------------------------------- /docs/assets/wp-tx-fold.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-tx-fold.png -------------------------------------------------------------------------------- /docs/assets/wp-tx-general.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/utxostack/RGBPlusPlus-design/c0b065c8bb8cc0a1813d27e9352ff694e1975ca3/docs/assets/wp-tx-general.png -------------------------------------------------------------------------------- /docs/light-paper-cn.md: -------------------------------------------------------------------------------- 1 | # RGB++ Protocol Light Paper (Draft) 2 | 3 | *Cipher from CELL Studio* 4 | 5 | > Special thanks to [Ajian](https://twitter.com/AurtrianAjian), [cyberorange](https://twitter.com/xcshuan), [Jan](https://twitter.com/busyforking), [Shawn](https://twitter.com/ShawnMelUni), and [DaPangDun](https://twitter.com/DaPangDunCrypto) for feedback and discussion. 6 | 7 | # 简介 8 | 9 | RGB++ 是一个基于 RGB 的扩展协议，利用一次性密封条和客户端验证技术来管理状态变更和交易验证。它通过同构绑定将比特币 UTXO 映射到 Nervos CKB 的 Cell 上，并利用 CKB 链和 Bitcoin 链上的脚本约束来验证状态计算的正确性和变更所有权的有效性。RGB++ 解决了原 RGB 协议在实际落地中的技术问题，并提供了更多的可能性，如区块链增强的客户端验证、交易折叠、共享状态与无主合约、非交互式转账等。它为比特币带来了无须跨链、不损失安全性的图灵完备合约扩展和性能扩展。 10 | 11 | ### 一次性密封 12 | 13 | 一次性密密封的概念最早由 [Peter Todd 在 2016 年](https://petertodd.org/2016/state-machine-consensus-building-blocks)提出，它允许你对一条消息锁上一个电子密封条，确保这条消息只能被使用一次。具体来说，我们可以使用比特币的未花费的交易输出（UTXO）作为消息的密封条，比特币系统的共识机制可以确保这些 UTXO 仅能被消费一次，也即这些密封条仅能被打开一次。 14 | 15 | RGB 协议利用这种基于比特币 UTXO 的一次性密封条，将 RGB 状态变更与比特币 UTXO 的所有权对应。因此比特币系统确保了 RGB 的状态所有权，以及可以通过 UTXO 历史来追溯所有的状态变更。一次性密封为 RGB 协议提供了由 Bitcoin 共识保障的防双花安全和交易分支追溯功能。 16 | 17 | ### 客户端验证 18 | 19 | RGB 协议包含的用户状态无法由比特币共识直接验证，用户必须通过链外计算确保 RGB 的状态变更符合预期。客户端验证技术允许用户只需要验证与自己有关的 UTXO 分支历史，而无需关心与自己无关的交易历史。RGB 的状态安全性通过客户端验证方式保障，不依赖任何中心化第三方。 20 | 21 | ### RGB 协议的问题 22 | 23 | 尽管 RGB 协议有非常多的优势，尤其它可以为 Bitcoin 提供几乎不妥协的合约扩展，但在实际应用中依然存在多个技术和产品问题。 24 | 25 | **DA 问题** 26 | 27 | 普通用户如何生成或获取交易历史的证明。普通用户使用简单的客户端产品时，并没有能力或资源保存所有的历史交易，也因此难以向交易对手方提供交易证明。 28 | 29 | **P2P 网络问题** 30 | 31 | RGB 交易作为 Bitcoin 的扩展交易，需要依赖一个 P2P 网络进行传播。用户之间在进行转账交易时，也需要进行交互式操作，接收方需要提供收条。这些都依赖一个独立于 Bitcoin 网络的 P2P 网络。 32 | 33 | **虚拟机与合约语言** 34 | 35 | RGB 协议的虚拟机目前主要是采用了 AluVM，作为新的虚拟机，目前缺乏完善的开发工具和实践代码。 36 | 37 | **无主合约问题** 38 | 39 | RGB 协议目前尚无完善的无主合约（公共合约）的交互方案。这导致多方交互难以实现。 40 | 41 | 42 | ### RGB++ 同构绑定 43 | 44 | ![binding](./assets/wp-binding.png) 45 | 46 | RGB++ 通过同构绑定技术解决了 RGB 协议遇到的问题，并赋予了 RGB 更多的可能性。在 RGB 协议中，最重要的两个组件是用来做所有权认定的 UTXO 和用来做状态管理与一次性密封的 commitment。RGB++ 的同构绑定将其中的 Bitcoin UTXO 一一映射到 CKB 的 Cell 上、使用 bitcoin utxo lock 来实现所有权同步，并使用 cell 的 data 和 type 来实现状态的维护。 47 | 48 | ### 区块链增强客户端验证 49 | 50 | 所有的 RGB++ 交易都会在 BTC 和 CKB 链上同步各出现一笔交易。前者与 RGB 协议的交易兼容，后者则取代了客户端验证的流程，用户只需要检查 CKB 上的相关交易即可验证这笔 RGB++ 交易的状态计算是否正确。但用户也可以不使用 CKB 链上的交易作为验证依据，利用 UTXO 的局部历史交易信息，用户可以脱离 CKB 链独立地对 RGB++ 交易进行验证（交易折叠等部分功能仍然需要依赖 CKB 的块头哈希做防双花验证）。 51 | 52 | # RGB++ 交易流程 53 | 54 | ![tx-general](./assets/wp-tx-general.png) 55 | 56 | ### 链外计算 57 | 58 | - 选中下一次要使用的一次性密封条，例如 btc_utxo#2 59 | - 链外计算并生成一笔将要发送到 CKB 上的 RGB++ 交易: CKB_TX_B 60 | - 链外计算 `commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)` 61 | 62 | ### BTC 交易提交 63 | 64 | - 生成并发送一笔比特币交易 Bitcoin_TX_A, 输入消耗 `btc_utxo#1`，输出通过 OP_RETURN 加入上面的 commitment 65 | 66 | ### CKB 交易提交 67 | 68 | - 发送上述 CKB 交易 CKB_TX_B 69 | - 用户的最新状态由 `CKB_TX_B.output.data` 维护 70 | - 下一次变更状态需要使用 `btc_utxo#2`、`CKB_TX_B.output` 71 | 72 | ### 链上验证 73 | 74 | - Bitcoin 验证相关的 utxo 只能被指定用户花费一次 75 | - CKB 上存在 Bitcoin 的轻客户端，它可以验证 Bitcoin 上的相关交易存在 Bitcoin 链上 76 | - Bitcoin 的相关交易作为 ckb 交易的 witness 被提交上来，协助验证 77 | - CKB 进一步验证该 btc 交易花费了正确的 utxo 78 | - CKB 进一步验证该 btc 交易承诺了正确的 commitment 79 | - CKB 验证 CKB 上的状态转移符合预订的合约规则 80 | 81 | ## RGB++ 客户端 82 | 83 | 不同于 RGB 协议，RGB++ 的所有交易都在 CKB 上并由 CKB 脚本约束验证，因此 RGB++ 无须独立客户端，用户只需要访问 Bitcoin 和 CKB 轻客户端即可验证所有交易。其中 CKB 轻客户端同样使用 PoW 算法可以实现最近的若干个块头即可验证所有历史交易和状态，进而利用同构绑定验证 RGB++ 的所有交易。 84 | 85 | # 交易折叠 86 | 87 | RGB++ 协议将 Bitcoin UTXO 与 CKB Cell 进行同构绑定，实现了 CKB Cell 验证支持的图灵完备 Bitcoin UTXO 交易。如果我们进一步利用 CKB Cell 的可编程能力，那么我们可以将多笔 CKB 交易与一笔 Bitcoin RGB++ 交易对应，这样就可以将低速低吞吐量的 Bitcoin 链使用高性能的 CKB 链进行扩容。 88 | 89 | ![tx-fold](./assets/wp-tx-fold.png) 90 | 91 | # 共享状态与无主合约 92 | 93 | ## 共享状态的平庸实现 94 | 95 | 共享状态一直是 UTXO 系统的难题，这里先讨论一种不考虑多人同时更新共享状态的平庸实现，再进一步讨论实际会采用的允许多人同时操作共享状态的解决方案。 96 | 97 | 考虑 CKB 上存在一个全局状态的 Cell，用来管理多用户共享的状态。典型地，它可以是一个算法稳定币的质押合约，用户将波动资产存入，并获得一个存款证明。全局状态由无主合约管理，所谓无主合约指的是任何人在满足合约的约束前提下都可以对状态进行变更，而不要求指定的数字签名提供方进行变更。无主合约的实现对协议的去中心化和抗审查有决定性的作用。 98 | 99 | 这里的平庸实现指的是 Global-state cell 有被其他用户占用的风险，这样 CKB TX 就会因为指定的 Global state utxo 不存在而无法成立。而 Bitcoin TX 需要先于 CKB TX 发送出来、并将其计算到 commitment 中，因此也无法进行后续的验证。 100 | 101 | ## 共享状态的状态争抢问题与解决方案 102 | 103 | 为了解决上述问题，我们引入了 Intent Cell 作为中介。用户将自己希望执行的动作确定性地写入 Intent Cell，后者则可以通过第三方聚合器的协作与全局状态 Cell 交互，批量将多方的 intent 进行计算，并将交互结果合并到标准的 shadow cell 上。 104 | 105 | # 非交互式转账 106 | 107 | 原始 RGB 协议的一个问题是收款方需要提供一个自己的 live utxo 作为 invoice 才能实施转账，这种方式要求收款方必须在线才能完成一笔普通的交易，增加了用户理解难度和产品复杂度。RGB++ 可以利用图灵完备环境的优势，将交互行为放置在 ckb 环境里面，采用发送-领取两步操作来实现非交互式转账逻辑。 108 | 109 | ## 发送 110 | 111 | 用户 A 向用户 B 发送资产时，只需要获知 B 的地址，并在 RGB++ 交易中向该地址转账，而不需要收款人提供 utxo 或 invoice。 112 | 113 | ![send tx](./assets/wp-send.png) 114 | 115 | ## 领取 116 | 117 | ![claim tx](./assets/wp-claim.png) 118 | 119 | CKB 的 lock 合约有能力验证 btc 地址对应的数字签名，因此接收方可以在 CKB 上构造 Tx C 来解锁对应的 CKB Cell，并将资产转移到自己的 utxo#2 上。从而完成了非交互式收款。 120 | 121 | # Coins 122 | 123 | RGB++ 上的 fungible 资产发行需要对应的数据结构标准和一致性验证标准。我们可以使用 ckb 的 xudt 标准作为它的同构绑定协议。 124 | 125 | ## 发行 126 | 127 | RGB++ coins 的发行有很多种方式，包括并不限于中心化分发、空投、认购等方式。代币的总量也可以选择不设上限和预设上限两种。对于预设上限的代币，可以使用状态共享方案在每次发行时验证已发行总量小于等于预设上限。 128 | 129 | ## 转移 130 | 131 | RGB++ coins 的转移非常简单，只需要将收款方和找零 utxo 分别对应到 ckb 的 shadow cell 即可。coins 的转移也可以通过交易折叠的方式只发生在 CKB 上，多笔交易后再将最后结果 commit 到 BTC 上。 132 | 133 | ## 隐私 134 | 135 | xudt 是一个透明的代币协议，我们也可以采用支持金额隐私和流向隐私的代币协议来强化 RGB++ coins 的隐私保护特性。例如，我们可以使用 bulletproof 算法，将 data 中的内容变成盲化金额，并在每次转让的交易中提供金额一致且非负的零知识证明。这样，只有交易当事人知道当前交易的具体金额信息，第三方观察者无法获知金额数据。 136 | 137 | 此外，我们还可以使用环签名实现转账流向的盲化。用户的 coin 在 CKB 上转账给环签名混淆器，然后再回流到由 bitcoin utxo 管理的地址上。通过这种方式切断资金流的历史轨迹，从而完成地址的隐私保护。 138 | 139 | # NFTs 140 | 141 | ## 发行 142 | 143 | RGB++ 的 NFT 资产发行也可以利用到 ckb 上现有的 NFT 协议，包括不限于 Spore、mNFT 和 CoTA 协议。以 Spore 为例，它将所有的元数据均保留的链上，实现了数据可用性的 100% 安全。而 CoTA 协议则是利用状态压缩技术，将 NFT 信息和持有数据压缩在 32 字节的的 SMT 中，提供了极致的成本优势。 144 | 145 | ## 转移 146 | 147 | RGB++ 中 NFT 的转让也非常简单，类似无须找零的 coins 转账。 148 | 149 | ![transfer](./assets/wp-transfer.png) 150 | 151 | # 闪电网络联通 152 | 153 | RGB 作为客户端验证协议天然支持状态通道和闪电网络，但受限于 Bitcoin 的脚本计算能力，在 Bitcoin 上实现非 btc 的闪电网络非常困难。通过 RGB++ 协议的包裹，我们可以基于 CKB 的图灵完备脚本系统实现 RGB++ 资产的状态通道以及闪电网络。这项技术有着巨大的商业前景，例如基于闪电网络的稳定币支付系统可以提供低于中心化系统的成本和性能优势，同时保障了去中心化和抗审查特性。 154 | 155 | # 应用举例 156 | 157 | ## Airdrop 158 | 159 | 给定一个地址列表和金额列表，我们可以使用 RGB++ 实现完整的 airdrop 应用。我们假设待领空投数据和已领地址列表均以 SMT 的信息保存在 cell data 中。用户即可通过自己的地址领取空投。 160 | 161 | ## DEX & AMM 162 | 163 | RGB++ 利用 UTXO 结构可以直接支持基于 UTXO 的资产交换协议，无须引入中介方。同时利用网格订单簿设计可以实现自动化做市商模式，有别于 Uniswap 的价格曲线做市商模式，**网格做市商模式**可定制化更强，更适合 UTXO 结构的资产交易。 164 | 165 | ![dex](./assets/wp-dex.png) 166 | 167 | 上面的例子是卖家挂单 RGB++ xudt，买家使用 Bitcoin 购买。交易结构为买家提供包含了足够数量 Bitcoin 的 buyer’s utxo 并提供 PBST 签名，买家则构造 CKB 上的交易来符合卖家的要求，最终买家将构造好的 CKB 交易发送给卖家，卖家将 BTC 交易和 CKB 交易先后上链完成交易。 168 | 169 | # 总结 170 | 171 | RGB++ 继承了 RGB 协议的核心思想，采用了不同的虚拟机和验证方案，用户无须独立的 RGB++ 客户端，只需要访问 Bitcoin 和 CKB 轻节点即可独立完成所有的验证。RGB++ 为 Bitcoin 带来了图灵完备合约扩展和数十倍的性能扩展。它没有使用任何跨链桥，而是使用了原生的客户端验证方案，确保了安全性和抗审查性。 172 | -------------------------------------------------------------------------------- /docs/light-paper-en.md: -------------------------------------------------------------------------------- 1 | # RGB++ Protocol Light Paper (Draft) 2 | 3 | *Cipher from CELL Studio* 4 | 5 | > Special thanks to [Ajian](https://twitter.com/AurtrianAjian), [cyberorange](https://twitter.com/xcshuan), [Jan](https://twitter.com/busyforking), [Shawn](https://twitter.com/ShawnMelUni), and [DaPangDun](https://twitter.com/DaPangDunCrypto) for feedback and discussion. 6 | 7 | 8 | # **Introduction** 9 | 10 | RGB++ is an extended RGB protocol by using single-use seals and client-side validation techniques to manage state changes and transaction verification. It maps the UTXO set of Bitcoin to the Cell of Nervos CKB via isomorphic bindings, and leverages scripting constraints on both CKB and Bitcoin chains to ensure the correctness of the state computations and the validity of the change ownership. 11 | 12 | Addressing technical challenges encountered in the implementation of the original RGB protocol, RGB++ brings a wide array of new possibilities including client-side validation, transaction folding, shared state across contracts, non-interactive transfers, and more. It introduces Turing-complete smart contract scalability and performance to Bitcoin without the need for cross-chain transactions and without compromising security. 13 | 14 | ### **Single-Use Seals** 15 | 16 | The concept of **single-use seals** was [first introduced by Peter Todd in July, 2016](https://petertodd.org/2016/state-machine-consensus-building-blocks). It allows for a lock of an electronic seal on a message, ensuring that the message can only be used once. Specifically, Bitcoin’s Unspent Transaction Outputs (UTXOs) can server as seals for messages, and the Bitcoin system’s consensus mechanism ensures that these UTXOs can only be spent once, meaning that these seals can only be opened once. 17 | 18 | The RGB protocol uses single-use seals, which is based on Bitcoin UTXOs, to map RGB state changes to Bitcoin UTXOs ownership. This allows the Bitcoin system to guarantee ownership of the RGB state, as well as traceability of all state changes through the UTXO history. With single-use seals, the RGB protocol inherits Bitcoin's double spending protection and transaction traceability, both enforced by Bitcoin's consensus mechanism. 19 | 20 | ### **Client-side Validation** 21 | 22 | The RGB protocol contains user state that cannot be directly verified by the Bitcoin consensus. This requires users to utilize off-chain computation to validate that RGB state changes meet expectations. Client-side validation enables users to only validate the relevant UTXO branch history, rather than irrelevant ones. RGB ‘s state security is provided through client-side validation without reliance on any centralized third party. 23 | 24 | ### **Problems with the RGB Protocol** 25 | 26 | While the RGB protocol has many advantages, especially in providing Bitcoin with virtually uncompromising contract extensions, there are several technical and product issues in practice. 27 | 28 | **DA Issues** 29 | 30 | **DA(Decentralized Authentication)** refers to whether the average user can generate or obtain proof of transaction history. When using a simple client-side product, average users lack the ability or resources to store full historical transaction data, making it difficult to provide cryptographic proof of transactions to counterparties. 31 | 32 | **P2P Network Issues** 33 | 34 | As an extension of Bitcoin, RGB transactions rely on a P2P network for propagation. Users also need to interact with each other when transferring money, for example, recipients need to provide receipts. This introduces dependencies on a P2P network that is independent of the Bitcoin network. 35 | 36 | **Virtual Machines and Contract Languages Immaturity** 37 | 38 | The RGB protocol currently uses AluVM as its primary virtual machine. As a new model, AluVM lacks mature development tools and code examples for practice. 39 | 40 | **Problems of Shared States and Unhosted Contracts** 41 | 42 | The RGB protocol presently lacks sophisticated solution for the interaction of unhosted contracts, which limits multi-party interactions to realize. 43 | 44 | ### **RGB++ isomorphic bindings** 45 | 46 | ![binding](./assets/wp-binding.png) 47 | 48 | RGB++ uses isomorphic bindings to solve the problems encountered by the RGB protocol and unlock more possibilities. In RGB, the two most important components are UTXOs, determining ownership, while commitments manage state and single-use seals. In contrast, RGB++ leverages isomorphic bindings to map Bitcoin UTXOs to Nervos' Cell, ensuring ownership synchronization through the utilization of Bitcoin's UTXO locking scripts. Meanwhile, the state maintenance is managed by the data and type fields of Nervos Cells. 49 | 50 | ### **Blockchain Enhanced Client-side Validation** 51 | 52 | All RGB++ transactions undergo synchronization, resulting in one transaction on both the BTC and CKB chains. The former is compatible with RGB protocol transactions, while the latter serves to replace the client-side validation process. Users only need to check the corresponding transaction on CKB to verify whether the state of the RGB++ transaction is correct. 53 | 54 | Also, users also have the option not to use the transactions on the CKB chain as the basis for verifications. By utilizing the local historical transaction information of UTXO, users can independently verify the RGB++ transaction from the CKB chain (note: some functions, such as transaction folding, still need to rely on the block header hash of CKB for anti-double-spending verification). 55 | 56 | # **RGB++ Transaction Process** 57 | 58 | ![tx-general](./assets/wp-tx-general.png) 59 | 60 | ### **Off-chain Computation** 61 | 62 | - Select the next **Single-Use Seals to be used**, e.g. btc_utxo#2; 63 | - Perform off-chain computation to generate an RGB++ transaction (**`CKB_TX_B`**) that will be sent to the CKB; 64 | - Get off-chain calculation: **`commitment = hash(CKB_TX_B | btc_utxo#1 | btc_utxo#2)`**. 65 | 66 | ### **BTC Transaction Submission** 67 | 68 | Generate and broadcast a Bitcoin transaction (**`Bitcoin_TX_A`**), input **`btc_utxo#1`** for consumption, outputting the above commitment via OP_RETURN. 69 | 70 | ### CKB Transaction Submission 71 | 72 | - Broadcast the CKB transaction (**`CKB_TX_B`**) mentioned above; 73 | - The user's latest state is maintained by **`CKB_TX_B.output.data`**; 74 | - The next state change requires the use of **`btc_utxo#2`** and **`CKB_TX_B.output`**; 75 | 76 | ### **On-chain Validation** 77 | 78 | - UTXOs related to Bitcoin validations can only be spent once by a given user; 79 | - A lightweight client on CKB validates the presence of relevant Bitcoin transactions on the Bitcoin chain; 80 | - Bitcoin's related transactions are submitted as witnesses in the CKB transaction for verification; 81 | - CKB then verifies that the BTC transaction spent the correct UTXO; 82 | - CKB further verifies that the BTC transaction commits to the correct commitment; 83 | - CKB verifies that the on-chain state transition complies with the predefined contract rules. 84 | 85 | ## **RGB++ Client** 86 | 87 | In contrast to the RGB protocol, all RGB++ transactions are on CKB and are validated by CKB script constraints. Therefore, RGB++ doesn't require a standalone client; users only need to access Bitcoin and CKB light client to verify all transactions. The CKB light client employs he PoW algorithm to verify all historical transactions and states with just a few recent block headers, which in turn facilitates the use of isomorphic bindings for verifying all RGB++ transactions. 88 | 89 | # **Transaction Folding** 90 | 91 | The RGB++ protocol uses isomorphic bindings between Bitcoin UTXOs and CKB Cell, enabling the implementation of Turing-complete Bitcoin UTXO transactions validated by CKB Cell. Specifically, by further leveraging the programmable capabilities of CKB Cells, multiple CKB transactions can be corresponded with a single Bitcoin RGB++ transaction. This approach allows the low speed, low throughput Bitcoin chain to benefit from higher scalability with the high performance CKB chain. 92 | 93 | ![tx-fold](./assets/wp-tx-fold.png) 94 | 95 | # **Shared State and Unhosted Contracts** 96 | 97 | ## Mediocre Implementation of Shared State 98 | 99 | Shared state has always been a challenge in UTXO systems. Here, we will first discuss a mediocre implementation that does not consider simultaneous updates to the shared state by multiple parties. Then, we will delve into a more practical solution that allows multiple parties to operate on the shared state simultaneously. 100 | 101 | Consider a global state cell on the CKB that manages the state shared by multiple users. Typically, it could be a staking contract for an algorithmic stablecoin, where users deposit volatile assets and receive a deposit proof. The global state is managed by an unhosted contract, meaning anyone can make changes to the state without requiring specific digital signatures from designated signatories. The implementation of an unhosted contract plays a crucial role in the decentralization and censorship resistance of the protocol. 102 | 103 | A mediocre implementation in this context means that there is a risk that the Global state Cell is occupied by another user, causing CKB TX fail because the specified Global state utxo does not exist. As the Bitcoin TX needs to be sent out and computed into the commitment before the CKB TX, subsequent validation becomes impossible. 104 | 105 | ## **The Issue of State Contentions in Shared States and Solutions** 106 | 107 | To address the above problem, we introduce the Intent Cell as an intermediary. Users can deterministically write down actions they wish to execute into the Intent Cell, which can interact with the global state Cell through the collaboration of a third-party aggregator, batch processing multiple parties’ intent and merging the results of the interaction into a standard shadow cell. 108 | 109 | # **Non-Interactive Transfers** 110 | 111 | One issue with the RGB protocol is receivers needs to provide a live UTXO as an invoice to initiate a transfer. This requires recipients stay online to complete a transaction, which increases the complexity for both user understanding and products. Instead, RGB++ leverages the Turing-complete environment by placing the interaction behavior in a CKB environment, and providing a two-step approach of send-receive to implement non-interactive transfer. 112 | 113 | ## **Send** 114 | 115 | When user A sends assets to user B, user A only needs to know user B's address - transferring funds to that address in the RGB++ transaction without requiring user B to provide any UTXOs or invoices. 116 | 117 | ![send tx](./assets/wp-send.png) 118 | 119 | ## **Receive** 120 | 121 | ![claim tx](./assets/wp-claim.png) 122 | 123 | The CKB lock contract has the ability to validate the digital signature of the BTC address. Therefore, the receiver can formulate a Tx C on CKB to unlock the corresponding CKB Cell and transfer the assets to their own utxo#2. This finalizes the non-interactive collection process. 124 | 125 | # Coins 126 | 127 | Issuing fungible assets on RGB++ requires corresponding data structure standards and consistency verification standards. We can adopt the [xUDT standard on CKB](https://talk.nervos.org/t/rfc-extensible-udt/5337) as the isomorphic binding protocol. 128 | 129 | ## **Issuance** 130 | 131 | There are many ways to issue fungible assets on RGB++, including but not limited to centralized distribution, airdrops, and subscriptions. The total supply of tokens can be either uncapped or pre-capped. For pre-capped tokens, a state sharing scheme can be employed during each issuance to validate that the total issued amount remains less than or equal to the preset cap. 132 | 133 | ## **Transfer** 134 | 135 | Transferring RGB++ coins is a straightforward process, involving mapping the recipient and remaining UTXO balances to the shadow cell of CKB. Also, transferring coins can be streamlined exclusively on CKB through transaction foldings. After multiple transactions are completed, the final results will be committed to BTC. 136 | 137 | ![transfer](./assets/wp-transfer.png) 138 | 139 | 140 | ## Privacy 141 | 142 | The xUDT protocol is a transparent token protocol. To enhance the privacy-preserving features of RGB++ coins, we can explore token protocols that offer both amount privacy and flow privacy. For instance, the bulletproof algorithm can be employed to transform the content in data into a blinded amount, with a zero-knowledge proof demonstrating the consistency and non-negativity of the amount in each transfer transaction. This ensures that only the parties involved in a transaction possess knowledge of the specific amount in the transaction, preventing third-party observers from accessing the date of amount. 143 | 144 | Additionally, ring signatures can be used to realize the blinding of the transfer flow. The user's coins are transferred to the ring signature obfuscator on CKB and then redirected back to the address managed by the Bitcoin UTXO. This strategy hides the historical trace of capital flow, thereby achieving enhanced privacy protection for the address. 145 | 146 | # NFTs 147 | 148 | ## Issuance 149 | 150 | Issuing NFT assets on RGB++ can also utilize existing CKB NFT standards, including but not limited to the [Spore Protocol](https://spore.pro/), mNFT, and [CoTA protocol](https://talk.nervos.org/t/rfc-cota-a-compact-token-aggregator-standard-for-extremely-low-cost-nfts-and-fts/6338). Taking Spore Protocol as an example, it stores all metadata on-chain, achieving 100% security in data availability. The CoTA protocol, on the other hand, is a compact token aggregator standard which compresses NFT information and holds data in 32-byte SMTs, providing ultimate cost advantages. 151 | 152 | ## **Transfer** 153 | 154 | The transfer of NFTs in RGB++ is also very simple, similar to a coins transfer with no change. 155 | 156 | # **Lightning Network Connectivity** 157 | 158 | RGB, functioning as a client-side authentication protocol, inherently supports state channels and the Lightning Network. However, due to Bitcoin's scripting limitations, it is very challenging to run non-BTC Lightning networks on the Bitcoin blockchain. By adopting the RGB++ protocol, we can leverage CKB's Turing-complete scripting system to implement state channels and Lightning networks specifically for RGB++ assets. Such technology holds significant commercial potential. For example, a stablecoin payment system built on the Lightning Network can deliver cost and performance advantages that surpass those offered by centralized systems while guaranteeing decentralization and censorship resistance. 159 | 160 | # **Examples of Applications** 161 | 162 | ## Airdrop 163 | 164 | Given a list of addresses and corresponding amounts, we can implement a complete airdrop application using RGB++. Assuming that both the pending airdrop data and the claimed address list are stored in cell data as SMT, users can easily collect airdrops from their own addresses. 165 | 166 | ## DEX & AMM 167 | 168 | RGB++ optimizes the UTXO structure, facilitating seamless support for UTXO-based asset exchange protocols without the need for intermediaries. Additionally, RGB++ adopts a grid trading design to enhance its Automated Market Maker (AMM) model. In comparison to Uniswap's AMM model, the grid trading model offers enhanced customization and suitability for trading UTXO-based assets. 169 | 170 | ![dex](./assets/wp-dex.png) 171 | 172 | The example above illustrates a scenario where a buyer is executing a purchase using $BTC in response to a seller's pending order for RGB++ xudt. As the transaction structure involves the buyer's utxo, containing sufficient amount of $BTC and a PBST signature, the buyer can creates a CKB transaction that meets the seller’s requirements. Afterwards, the buyer sends this signed CKB transaction to the seller. The seller then submits the BTC transaction and CKB transaction on-chain, one after the other, to complete the trade. 173 | 174 | # **Summary** 175 | 176 | RGB++ inherits the core idea of the RGB protocol while adopting a different virtual machine and validation scheme. Users can independently validate transactions by accessing Bitcoin and CKB light nodes, without needing a separate RGB++ client. In general, RGB++ brings Turing-complete contract scalability and achieves over ten times [performance scaling](https://www.ibm.com/docs/en/zos/2.1.0?topic=storage-tape-capacity-performance-scaling) to Bitcoin. Notably, instead of using cross-chain bridges, RGB++ implements native client-side validation for enhanced security and censorship resistance. 177 | -------------------------------------------------------------------------------- /docs/lockscript-design-prd-cn.md: -------------------------------------------------------------------------------- 1 | # RGB++ 合约规范 2 | 3 | Authors: Cipher Wang, JJY 4 | 5 | Contributors: CyberOrange, Ian, Jan 6 | 7 | # 概述 8 | 9 | ## 关于同构绑定的要求和限制 10 | 11 | 同构绑定要求 RGB++ 交易必须在 BTC 上提交, 用户通过在 BTC 提交一次性密封来描述对 RGB++ cells 的操作。用户需要先构造 CKB raw tx 以及 RGB++ commitment，再把 commitment 提交到 BTC，最后再将 CKB TX 上链。这里面的一些约束条件有： 12 | 13 | - RGB++ Cell 的 lock 中必须指定代表所有权的 BTC UTXO 信息（btc_tx + index） 14 | - ckb_tx 中的 RGB++ Cell 依赖 btc_tx，如果 btc_tx.commitment 再包含 ckb_tx，这就死锁了，因此，**Commitment 只能包含 ckb tx 的部分信息** 15 | - Commitment 只会包含前 N 个 Inputs, Outputs 16 | - Commitment 必须覆盖所有 Type 不为空的 Inputs 以及 Outputs 17 | - CKB TX 可以在 N 个 Inputs, Outputs 后使用额外的 Type 为空的 Inputs, Outputs，构造者可以利用这个规则修改交易的手续费 18 | - Cell 在创建时不会执行 Lock 脚本验证，因此任何人都可以创建 RGB++ Cell 并使用任意的 BTC UTXO 作为 Lock args，我们把这种交易理解成转移 cell 所有权到 BTC UTXO 上，此类的 Cell 在使用时与上述逻辑一致。 19 | 20 | # 合约需求 21 | 22 | 需要如下合约： 23 | 24 | - RGBPP_lock 用来处理与 RGB++ Cell 的解锁； 25 | - BTC_TIME_lock 时间锁，当用户资产从 L1 leap 到 L2 时必须使用该 Lock 锁定一定区块数。 26 | 27 | ## 合约的 Config Cell 28 | 29 | RGBPP_lock / BTC_TIME_lock 合约需要读取轻节点，因此我们必须保存相关合约的 type_hash。由于不希望引入硬编码的合约依赖，我们引入 Config Cell 的概念来解决此类配置问题。 30 | 31 | 32 | 部署合约时，要求 contract code cell 和 config cell 在同一笔交易的 outputs 内完成创建。 33 | 34 | ```yaml 35 | # BTC_TIME_lock 36 | inputs: any cells 37 | outputs: 38 | BTC_TIME_lock code cell 39 | time_lock_config cell 40 | ... 41 | 42 | # RGBPP_lock 43 | inputs: any cells 44 | outputs: 45 | RGBPP_lock code cell 46 | rgb_lock_config cell 47 | ... 48 | ``` 49 | 合约通过以下方式找到 config cell 50 | 51 | ```yaml 52 | 1. load_script 找到目前的 合约的 type_hash 53 | 2. 通过 type_hash 找到 cell dep 符合且 out_point.index == 1 的 cell deps 的 index 54 | 3. load 这个 cell dep 的 data 即得到全局配置 55 | ``` 56 | 57 | ```rust 58 | struct RGBPPConfig { 59 | version: Uint16, 60 | // Type hash of bitcoin light client 61 | bitcoin_lc_type_hash: Byte32, 62 | // Type hash of bitcoin time lock contract 63 | bitcoin_time_lock_type_hash: Byte32, 64 | } 65 | ``` 66 | 每次更新合约都必须和 Config Cell 一起更新，并且遵守更新规则。 67 | 68 | ## 合约数据结构 69 | 70 | ### RGBPP_lock 71 | 72 | ```yaml 73 | RGBPP_lock: 74 | code_hash: 75 | RGBPP_lock 76 | args: 77 | out_index | %bitcoin_tx% 78 | ``` 79 | 80 | - RGBPP_lock: 81 | - out_index：UTXO index, Cell 的所有权属于该 UTXO 82 | - bitcoin_tx: BTC txid 83 | 84 | ### BTC_TIME_lock 85 | 86 | ```yaml 87 | BTC_TIME_lock: 88 | args: lock_script | after | %new_bitcoin_tx% 89 | ``` 90 | 91 | - BTC Time lock: 92 | - lock_script 解锁后 Cell 的拥有者 93 | - after 要求 new_bitcoin_tx 超过 after 个确认后可以解锁 94 | 95 | ## RGBPP_Lock 解锁逻辑 96 | 97 | 100 | 101 | **Cell 解锁验证流程** 102 | 103 | ![uib](./assets/lock-verify.png) 104 | 105 | - 解锁者提供包含 RGB++ commitment 的 `btc_tx`： 106 | - 包含在 CKB 上的 BTC 轻客户端中 107 | - inputs 中包含与要解锁的 cell.lock 对应的 btc utxo input，即 `btc_tx.inputs[i] == previous_bitcoin_tx | out_index` 108 | - outputs 中有且仅有一个 OP_RETURN，包含 `commitment` 109 | - `self.lockargs.%new_bitcoin_tx% = btc_tx` 110 | - 该 `commitment` 为以下内容的 hash，算法为 `double sha256(”RGB++” | messages)` 111 | - `version: u16`，必须为 0 112 | - `inputs_len:u8` 113 | - 表示 commitments 包含前 n 个 inputs cells 114 | - 必须 >= 1 115 | - 所有 type 不为空的 input cell 必须被包含在 inputs_len 中 116 | - `outputs_len:u8` 117 | - 表示 commitments 包含前 n 个 outputs cells 118 | - 必须 >= 1 119 | - 所有 type 不为空的 output cell 必须被包含在 outputs_len 中 120 | - `CKB_TX.inputs[:inputs_len]` 121 | - `CKB_TX.outputs_sub[:outputs_len]`, 包含全部数据，除了 122 | - 不包含 `lockargs.%new_bitcoin_tx% = btc_tx` 123 | - 交易中其余资产仍然被 RGB++ Lock 保护，即所有 outputs 中 type 不为空的 cells 必须使用以下两种 lock 之一 124 | - RGBPP_lock 125 | - BTC_TIME_lock 126 | - 要求 `lockargs.after ≥ 6` 127 | - 要求 `lockargs.new_bitcoin_tx == btc_tx` 128 | 129 | **tips** 130 | 131 | - inputs_len / outputs_len 可以由最后一个有 type 的 input / output cell 的位置计算出 132 | - commitment 至少包含一个 input 和 output, 即使所有 inputs 和 outputs 的 type 都为空 133 | - SDK 可以修改 commitment 之外的 cells 调整手续费 134 | 135 | ## BTC_TIME_lock 解锁逻辑 136 | 137 | ```yaml 138 | lock.args: lock_hash | after | %new_bitcoin_tx% 139 | ``` 140 | 141 | - lock_script 为解锁后需要释放到的目标接受者 142 | - 解锁交易中每个 BTC_TIME_lock input 必须在相同 index 对应一个 output 143 | - output 的 lock 为 lock_script 其余字段 type, data, capacity 需要和 input 一致 144 | - after 要求 new_bitcoin_tx 已经超过 after 个确认 145 | - 解锁后的 cell 持有人的 lock 符合 lock_script 146 | 147 | # 交易逻辑 148 | 149 | ## L1 转账/操作 150 | 151 | **定义：CKB 上输入输出的资产 cell（定义：type ≠ null） 均为 RGBPP_lock** 152 | 153 | ```yaml 154 | # BTC_TX 155 | input: 156 | btc_utxo_1 # =(previous_btc_tx | out_index) 157 | ... 158 | output: 159 | OP_RETURN: commitment 160 | btc_utxo_3 # =(new_bitcoin_tx | out_index) 161 | btc_utxo_4 # =(new_bitcoin_tx | out_index) 162 | 163 | # CKB_TX 164 | input: 165 | rgb-xudt: 166 | type: 167 | code: xudt 168 | args: 169 | lock: 170 | code: RGBPP_lock 171 | args: btc_utxo_1 = (out_index | previous_btc_tx) 172 | 173 | output: 174 | xudt: 175 | type: xudt 176 | lock: 177 | code: RGBPP_lock 178 | args: out_index = 1 | %new_bitcoin_tx% 179 | 180 | xudt: 181 | type: xudt 182 | lock: 183 | code: RGBPP_lock 184 | args: out_index = 2 | %new_bitcoin_tx% 185 | ``` 186 | 187 | ## L1 → L2 Leap 操作 188 | 189 | **定义：CKB 上输入的资产 cell 的 lock 均为 RGB lock，输出的资产 cell 的 lock 至少一个或全部为 BTC_TIME_lock，其余为 RGBPP_lock** 190 | 191 | 这里需要在 CKB 上引入一种新的时间锁 Lock: **BTC_TIME_lock** 192 | 193 | ```yaml 194 | # BTC_TX 195 | input: 196 | btc_utxo_1 197 | ... 198 | output: 199 | OP_RETURN: commitment 200 | btc_utxo_3 201 | 202 | # CKB_TX 203 | input: 204 | rgb_xudt: 205 | type: xudt 206 | lock: 207 | code: RGBPP_lock 208 | args: out_index | source_tx 209 | 210 | output: 211 | rgb_xudt: 212 | type: xudt 213 | lock： 214 | code: BTC_TIME_lock 215 | args: lock_script | after | %new_bitcoin_tx% 216 | 217 | rgb_xudt: 218 | type: xudt 219 | lock: 220 | code: RGBPP_lock 221 | args: out_index=1 | %new_bitcoin_tx% 222 | ``` 223 | 224 | 等到足够多的 BTC 区块确认后，可以解锁 BTC_TIME_lock 的 cell。 225 | 226 | > 注意：每个 BTC_TIME_lock input 对应的 output 上必须存在对应解锁后的 cell, 除 lock 外其余字段保持不变 227 | 228 | ```yaml 229 | # CKB_TX 230 | input: 231 | rgb_xudt: 232 | type: xudt 233 | lock: 234 | code: BTC_TIME_lock 235 | args: lock_script | 6 | btc_tx 236 | 237 | output: 238 | rgb_xudt: 239 | type: xudt 240 | lock: 241 | lock_script 242 | 243 | witness: 244 | # proof of 6 confirmations after #btx_tx 245 | ``` 246 | 247 | ## L2 → L1 Leap 操作 248 | 249 | **定义：输入侧没有 RGB_lock，输出侧有 RGBPP_lock** 250 | 251 | ```yaml 252 | # CKB TX 253 | input: 254 | xudt: 255 | type: xudt 256 | lock: 257 | ckb_address1 258 | 259 | output: 260 | xudt: 261 | type: xudt 262 | lock: 263 | ckb_address2 264 | 265 | rgb_xudt: 266 | type: xudt 267 | lock: 268 | args: btc_utxo 269 | ``` 270 | 271 | # RGB++ 资产发行 272 | 273 | ## 纯 L1 方式发行 RGB++ 资产 274 | 275 | 使用 L1 方式发行 RGB++ 要求发行人使用 bitcoin 上的交易，utxo 或其他 id 作为身份标识符来发行资产，这样才可以做到无须 L2 辅助即可完全实现 CSV。具体发行方案有多种，我们这里列出两种简单方案。 276 | 277 | ### 直接发行 278 | 279 | 发行人需要先构造一个使用特定 BTC UTXO 作为 RGBPP_lock 的 issue_cell。该步骤无须经过同构绑定，后即可用这个 cell 进行一次性发行。 280 | 281 | ```yaml 282 | # BTC TX 283 | input: 284 | btc_utxo#0 285 | ... 286 | output: 287 | commitment 288 | btc_utxo#1 289 | ... 290 | 291 | # CKB TX 292 | input: 293 | issue_cell: 294 | RGBPP_lock: 295 | args: btc_utxo#0 296 | 297 | output: 298 | xudt_cell: 299 | data: amount 300 | type: 301 | code: xudt 302 | args: hash(RGBPP_lock|btc_utxo#0) 303 | lock: 304 | code: RGBPP_lock 305 | args: btc_utxo#1 306 | ``` 307 | ### 区块区间发行 308 | 309 | 区块区间发行需要将 xudt 的发行模式从 lock 发行改为 type 发行，即创建一种新的 xudt，或插件，使得发行的 xudt 的 type.args，即资产 id 不是 lockhash，而是某些 btc 链的参数即可 310 | 311 | ```yaml 312 | # BTC TX 313 | input: 314 | btc_utxo#0 315 | ... 316 | output: 317 | commitment 318 | btc_utxo#1 319 | ... 320 | 321 | # CKB TX 322 | input: 323 | issue_cell: 324 | RGBPP_lock: 325 | args: btc_utxo#0 326 | 327 | output: 328 | xudt_cell: 329 | data: amount 330 | type: 331 | code: xudt_modified 332 | args: 333 | hash_of: 334 | start_block, 335 | end_block, 336 | max_per_tx, 337 | token_name 338 | lock: 339 | code: RGBPP_lock 340 | args: btc_utxo#1 341 | ``` 342 | 343 | 上面的例子中，在[start_block, end_block] 区间发起的交易，任何人都可以在 BTC L1 上实现公平发射发行，以平等的机会获得代币。 344 | 345 | ## L2 发行后跳转到 L1 346 | 347 | 比较简单，也更灵活，不再赘述。 348 | -------------------------------------------------------------------------------- /docs/lockscript-design-prd-en.md: -------------------------------------------------------------------------------- 1 | # RGB++ Script Standard 2 | 3 | Authors: Cipher Wang, JJY 4 | 5 | Contributors: CyberOrange, Ian, Jan 6 | 7 | # Overview 8 | 9 | ## Requirements and Limitations on Isomorphic Binding 10 | 11 | Isomorphic Binding requires that RGB++ transactions must be submitted on BTC chain, and that the user use single-use seals on BTC to describe the operation on RGB++ cells. The user needs to construct the CKB raw tx and the RGB++ commitment first, then submit the commitment to BTC, and finally send the CKB TX on-chain. 12 | 13 | However, there are some constraints: 14 | 15 | - The BTC UTXO information that represents ownership must be specified in the `lock` of the RGB++ Cell (`btc_tx` + `index`). 16 | - The RGB++ Cell in `ckb_tx` depends on `btc_tx`; if `btc_tx.commitment` includes `ckb_tx`, it results in a deadlock. Thus, **the commitment can only contain these following information of the CKB transaction**: 17 | - Commitment includes only the first N Inputs and Outputs; 18 | - Commitment must cover all Inputs and Outputs where `Type` is not null; 19 | - After the initial N Inputs and Outputs, the CKB transaction can include additional Inputs and Outputs with a null `Type`. This rule allows for modifications to the transaction fee. 20 | - Cell is created without lock script validation, allowing anyone to create an RGB++ Cell using any BTC UTXO as `LockArgs`. This process essencially transfers ownership of the Cell to a BTC UTXO. Also, the operation of this type of Cell follows the same principles outlined above. 21 | 22 | # Contract Requirements 23 | 24 | The following contract is required: 25 | 26 | - `RGBPP_lock`: this is designed to handle the unlocking process of the RGB++ Cell; 27 | - `BTC_TIME_lock`: this is a time lock used to secure a specified number of blocks when assets leap from Layer 1 (L1) to Layer 2 (L2). 28 | 29 | ## **Config Cell** of the Contract 30 | 31 | Both the `RGBPP_lock` and `BTC_TIME_lock` require the [BTC light client](https://github.com/ckb-cell/ckb-bitcoin-spv-contracts/blob/master/contracts/ckb-bitcoin-spv-type-lock/README.md) data, necessitating the storage of the associated contract's `type_hash`. To avoid hardcoded dependencies, the concept of Config Cell is introduced here to address this configuration issue. 32 | 33 | When deploying a contract, both the `contract code cell` and the `config cell` must be included in the same transaction's outputs. 34 | 35 | ``` 36 | # BTC_TIME_lock 37 | inputs: any cells 38 | outputs: 39 | BTC_TIME_lock code cell 40 | time_lock_config cell 41 | ... 42 | 43 | # RGBPP_lock 44 | inputs: any cells 45 | outputs: 46 | RGBPP_lock code cell 47 | rgb_lock_config cell 48 | ... 49 | ``` 50 | 51 | The contract follows these steps to identify Config Cell: 52 | 53 | ``` 54 | 1. Use load_script to retrieve the type_hash of the current contract; 55 | 2. Use type_hash to identify the index that its cell dep matches and has out_point.index == 1; 56 | 3. Load the data from this cell dep to fetch global configuration settings. 57 | ``` 58 | 59 | ``` 60 | struct RGBPPConfig { 61 | version: Uint16, 62 | // Type hash of bitcoin light client 63 | bitcoin_lc_type_hash: Byte32, 64 | // Type hash of bitcoin time lock contract 65 | bitcoin_time_lock_type_hash: Byte32, 66 | } 67 | ``` 68 | 69 | Whenever the contract is updated, the Config Cell must be updated as well, and these updates must adhere to predefined rules. 70 | 71 | ## Data Structure of the Contract 72 | 73 | ### **RGBPP_lock** 74 | 75 | ``` 76 | RGBPP_lock: 77 | code_hash: 78 | RGBPP_lock 79 | args: 80 | out_index | %bitcoin_tx% 81 | ``` 82 | 83 | - `RGBPP_lock`: 84 | - out_index: UTXO index, the ownership of the Cell belongs to this UTXO 85 | - bitcoin_tx: BTC txid 86 | 87 | ### **BTC_TIME_lock** 88 | 89 | ``` 90 | BTC_TIME_lock: 91 | args: lock_script | after | %new_bitcoin_tx% 92 | ``` 93 | 94 | - `BTC_TIME_lock`: 95 | - refers to the owner of Cell once `lock_script` is unlocked; 96 | - `after` requires that `new_bitcoin_tx` can only be unlocked after it has received more than the number of confirmations specified by the `after` . 97 | 98 | ## **RGBPP_Lock Unlock Logic** 99 | 100 | 💡 For Cell of the RGB++ Asset on L1 Address (`btc_utxo`) 101 | 102 | ### **Cell Unlock Validation Process** 103 | 104 | ![uib](./assets/lock-verify.png) 105 | 106 | The process for unlocking involves providing a `btc_tx` with the RGB++ commitment: 107 | 108 | - It is included within the BTC light client on CKB. 109 | - Inputs should include the BTC UTXO Input corresponding to the cell.lock to be unlocked, i.e., `btc_tx.inputs[i] == previous_bitcoin_tx | out_index`. 110 | - Outputs must contain only one `OP_RETURN`, which include `commitment`. 111 | - `self.lockargs.%new_bitcoin_tx% = btc_tx`. 112 | 113 | The `commitment` is created using the `double sha256("RGB++" | messages)` method, and should satisfy the following rules: 114 | 115 | - `version: u16` should always be 0; 116 | - `inputs_len: u8`: 117 | - Specifies the commitment includes the first n input cells; 118 | - Must be >= 1; 119 | - All input cells with a non-null type must be included within `inputs_len` ; 120 | - `outputs_len: u8`: 121 | - Specifies the commitment includes the first n output cells; 122 | - Must be >= 1; 123 | - All output cells with a non-null type must be included within `outputs_len` ; 124 | - `CKB_TX.inputs[:inputs_len]` ; 125 | - `CKB_TX.outputs_sub[:outputs_len]`includes all data except for: 126 | - `lockargs.%new_bitcoin_tx% = btc_tx` . 127 | 128 | The remaining assets in the transaction is secured by the RGB++ Lock. All output cells that have a non-null type must use one of the following locks: 129 | 130 | - `RGBPP_lock` 131 | - `BTC_TIME_lock`, which requires: 132 | - `lockargs.after ≥ 6` ; 133 | - `lockargs.new_bitcoin_tx == btc_tx`. 134 | 135 | Tips: 136 | 137 | - `inputs_len` and `outputs_len` can be calculated by the position of the last input or output cell with a `type` ; 138 | - The commitment must include at least one input and one output, even if all input `type` and output `type` are null; 139 | - SDKs can alter cells outside of the commitment to adjust the transaction fee. 140 | 141 | ## **BTC_TIME_lock Unlock Logic** 142 | 143 | ``` 144 | lock.args: lock_hash | after | %new_bitcoin_tx% 145 | ``` 146 | 147 | - The `lock_script` identifies the recipient who will receive the assets after the lock is unlocked: 148 | - For each `BTC_TIME_Lock` input in a transaction, there must be a corresponding output at the same index; 149 | - The lock of the output must be `lock_script`, with the other fields such as `type`, `data`, and `capacity` must be identical to those in the input. 150 | - `after` requires that the `new_bitcoin_tx` has more than the number of confirmations specified by the `after` ; 151 | - after unlocking, the `lock` of the cell holder must match the `lock_script`. 152 | 153 | # **Transaction Logic** 154 | 155 | ## **L1 Transfers/Operations** 156 | 157 | **Definition**: The locks of `non-null asset type` inputs and outputs in a CKB transaction are all RGBPP_lock. 158 | 159 | ``` 160 | # BTC_TX 161 | input: 162 | btc_utxo_1 # =(previous_btc_tx | out_index) 163 | ... 164 | output: 165 | OP_RETURN: commitment 166 | btc_utxo_3 # =(new_bitcoin_tx | out_index) 167 | btc_utxo_4 # =(new_bitcoin_tx | out_index) 168 | 169 | # CKB_TX 170 | input: 171 | rgb-xudt: 172 | type: 173 | code: xudt 174 | args: 175 | lock: 176 | code: RGBPP_lock 177 | args: btc_utxo_1 = (out_index | previous_btc_tx) 178 | 179 | output: 180 | xudt: 181 | type: xudt 182 | lock: 183 | code: RGBPP_lock 184 | args: out_index = 1 | %new_bitcoin_tx% 185 | 186 | xudt: 187 | type: xudt 188 | lock: 189 | code: RGBPP_lock 190 | args: out_index = 2 | %new_bitcoin_tx% 191 | ``` 192 | 193 | ## L1 → L2 Leap 194 | 195 | **Definition**: On CKB, the lock for input asset cell is `RGB_lock`. For output asset cells, at least one, and possibly all, will be `BTC_TIME_lock`; while the remaining output asset cells use `RGBPP_lock`. 196 | 197 | `BTC_TIME_lock`, as a new type of timelock on CKB, is introduced here. 198 | 199 | ``` 200 | # BTC_TX 201 | input: 202 | btc_utxo_1 203 | ... 204 | output: 205 | OP_RETURN: commitment 206 | btc_utxo_3 207 | 208 | # CKB_TX 209 | input: 210 | rgb_xudt: 211 | type: xudt 212 | lock: 213 | code: RGBPP_lock 214 | args: out_index | source_tx 215 | 216 | output: 217 | rgb_xudt: 218 | type: xudt 219 | lock： 220 | code: BTC_TIME_lock 221 | args: lock_script | after | %new_bitcoin_tx% 222 | 223 | rgb_xudt: 224 | type: xudt 225 | lock: 226 | code: RGBPP_lock 227 | args: out_index=1 | %new_bitcoin_tx% 228 | ``` 229 | 230 | After enough BTC blocks have been confirmed, the `BTC_TIME_lock` cells can be unlocked. 231 | 232 | > Note: Each output corresponding to a `BTC_TIME_lock` input must have an unlocked cell where all fields should remain unchanged from the input except for the lock field. 233 | > 234 | 235 | ``` 236 | # CKB_TX 237 | input: 238 | rgb_xudt: 239 | type: xudt 240 | lock: 241 | code: BTC_TIME_lock 242 | args: lock_script | 6 | btc_tx 243 | 244 | output: 245 | rgb_xudt: 246 | type: xudt 247 | lock: 248 | lock_script 249 | 250 | witness: 251 | # proof of 6 confirmations after #btx_tx 252 | ``` 253 | 254 | ## **L2 → L1 Leap** 255 | 256 | **Definition**: No RGBPP_lock in the transaction Inputs, while Outputs has RGBPP_lock. 257 | 258 | 259 | 260 | ``` 261 | # CKB TX 262 | input: 263 | xudt: 264 | type: xudt 265 | lock: 266 | ckb_address1 267 | 268 | output: 269 | xudt: 270 | type: xudt 271 | lock: 272 | ckb_address2 273 | 274 | rgb_xudt: 275 | type: xudt 276 | lock: 277 | args: btc_utxo 278 | 279 | ``` 280 | 281 | # **RGB++ Asset Issuance** 282 | 283 | ## Bitcoin L1 Issuance of RGB++ Assets 284 | 285 | To issue RGB++ assets using Bitcoin's Layer 1, the issuer must initiate a bitcoin transaction that uses UTXO or other id as an identifier. This method enables the implementation of CSV on Layer 1, eliminating the need for Layer 2 involvement. There are various issuance methods, the following sections will discuss two primary issuance methods: direct issuance and inter-block issuance. 286 | 287 | ### **Direct Issuance** 288 | 289 | An issuer needs to create a specific UTXO as an issue_cell lock. The issue_cell will then be used for a one-time issuance. 290 | 291 | ``` 292 | # BTC TX 293 | input: 294 | btc_utxo#0 295 | ... 296 | output: 297 | commitment 298 | btc_utxo#1 299 | ... 300 | 301 | # CKB TX 302 | input: 303 | issue_cell: 304 | RGBPP_lock: 305 | args: btc_utxo#0 306 | 307 | output: 308 | xudt_cell: 309 | data: amount 310 | type: 311 | code: xudt 312 | args: hash(RGBPP_lock|btc_utxo#0) 313 | lock: 314 | code: RGBPP_lock 315 | args: btc_utxo#1 316 | ``` 317 | 318 | ### **Inter-block issuance** 319 | 320 | Inter-block issuance involves altering the issuance mode of an extensible User-Defined Token ([xUDT](https://talk.nervos.org/t/rfc-extensible-udt/5337)) from `lock` to `type`. This means that the new xUDT's type.args (a.k.a. asset ID) is not lock_hash but some parameters on the BTC chain. 321 | 322 | ``` 323 | # BTC TX 324 | input: 325 | btc_utxo#0 326 | ... 327 | output: 328 | commitment 329 | btc_utxo#1 330 | ... 331 | 332 | # CKB TX 333 | input: 334 | issue_cell: 335 | RGBPP_lock: 336 | args: btc_utxo#0 337 | 338 | output: 339 | xudt_cell: 340 | data: amount 341 | type: 342 | code: xudt_modified 343 | args: 344 | hash_of: 345 | start_block, 346 | end_block, 347 | max_per_tx, 348 | token_name 349 | lock: 350 | code: RGBPP_lock 351 | args: btc_utxo#1 352 | ``` 353 | 354 | In the above example, for transactions initiated within the [`start_block, end_block`] interval, anyone can executes a fair launch on BTC L1, ensuring that everyone has equal chance of token distribution. 355 | 356 | ## **Leap to L1 Following L2 Issuance** 357 | 358 | This process is straightforward and offers greater flexibility, hence it will not be discussed in this document. 359 | -------------------------------------------------------------------------------- /docs/security-analysis-cn.md: -------------------------------------------------------------------------------- 1 | # RGB++ 深入讨论：安全性分析 2 | 3 | *Cipher from CELL Studio & Nervos Foundation* 4 | 5 | > Special thanks to [Ren Zhang](https://scholar.google.com/citations?hl=en&user=JB1uRvQAAAAJ), [Ian](https://github.com/doitian), and [c4605](https://talk.nervos.org/u/c4605/summary) for feedback and discussion. 6 | > The RGB receiver optimization approach is inspired by [Jason Cai](https://twitter.com/CryptoStwith). 7 | 8 | ## **PoW 比你想象的更安全** 9 | PoW 的安全性风险在于区块 revert/reorg，从而导致双花。只要有一个诚实矿工，用户的状态/资产就不会计算错误，只有可能出现因区块重整导致的双花交易损失。因此 PoW 的核心安全假设就是 N 个区块后交易就几乎不会被 revert 了，例如 Bitcoin 普遍认为 6 区块甚至更少即可。 10 | 11 | 显然，6确认的 BTC 肯定比1确认更安全，那么 PoW 确认数和安全性是线性关系吗？并不是，**推翻区块的难度随着区块深度指数增长**，这个指数增长具体的参数已经有几十篇论文在讨论了。随着时间的推移，大家发现“NC比从前以为的更安全”。 12 | 13 | 根据 [Ren Zhang](https://scholar.google.com/citations?hl=en&user=JB1uRvQAAAAJ) 博士的计算，假设敌手算力占比30%，要实现比特币中孤块率为0、6个块确认的安全性，当 CKB 的孤块率设定成 2.5% 的时候，需要23.29个块确认即可达到相同的安全性 。通过这样的等价关系，我们可以在后续的讨论中方便地讨论 RGB++ 协议中各种典型操作的安全性。 14 | 15 | ![pow](./assets/sa-pow.png) 16 | ***PoW 安全性的示意图（非理论计算）*** 17 | 18 | ## **RGB 的安全性** 19 | RGB 通过一次性密封和客户端验证的方式实现了在 Bitcoin UTXO 上绑定 RGB 的状态和合约，为 Bitcoin 提供了图灵完备的扩展。交易安全性有两类，一类是状态计算的正确性；一类是交易确定性，即双花风险。客户端验证确保了状态计算的正确性，每个人负责自己的状态，不依赖任何第三方。而基于 BTC UTXO 的一次性密封确保了双花 RGB 的难度和双花 BTC 的难度相同。因此，我们可以说** RGB 100% 继承了 Bitcoin 的安全性**。用户需要多安全，就按照比例等待多少个 BTC 确认即可。 20 | 21 | ## **RGB++ 的安全性** 22 | ### **L1 交易安全性** 23 | RGB++ 的 L1 交易指的是 RGB++ 交易的 UTXO 的"持有人" 是 Bitcoin 的 UTXO。即只有消费 Bitcoin UTXO 才能操作或更新 RGB++ UTXO。这种情况下，虽然每一笔 RGB++ 交易都同步发起一笔 CKB 交易，但其安全性和 CKB 没有关系，CKB 仅作为 DA 和状态公示来使用。**这种情况下，RGB++ L1 的交易安全性和 RGB 交易相同，也是完全继承了 BTC 的安全性。** 24 | 25 | ### **L2 交易安全性** 26 | L2 交易即 100% 发生在 CKB 上的交易，显然它的安全性 100% 由 CKB 负责。但由于开篇提出的 PoW 安全的非线性特性，24个区块的 ckb 确认即可等价于 6 确认的 BTC 确认，因此我们也可以说 L2 交易安全性与 L1 交易安全性等价（需要更多区块确认，但事实上更短确认时间）。 27 | 28 | 能做到这一点的前提是 RGB++ 的同构映射链必须是 PoW 的，如果它是 PoS 的链，无论等待多少个区块，它安全性上限都是 PoS 的 stake 量，无法与 Bitcoin 安全性等价。 29 | 30 | ### **JUMP 操作** 31 | RGB++ 协议中用户的资产既可以在 Bitcoin 上流转，也可以随时到 CKB 上流转，或者反向操作。在切换的过程不需要跨链桥，更不需要信任任何多签方。我们将资产或状态在 Bitcoin 上和 CKB 上流转的切换称为 Jump。Jump 操作前后，影响 RBG++ 协议安全性的核心点在于： 32 | 33 | - 一次性密封条，从使用 Bitcoin UTXO 变为使用 CKB UTXO，或相反 34 | 35 | - 客户端验证所需要的数据保持不变，都是 CKB 上的同构绑定交易 36 | 37 | Jump 操作时，用户需要在两条链上分别等待足够的区块数，以获得安全性。 38 | 39 | ## **兼顾用户体验** 40 | 根据上面的讨论，等待足够多的区块数确实可以获得足够的安全性，但用户体验实在太差了。考虑平庸的方案，每个 RGB++ L1 交易要等待 6 个 BTC 确认再进行下一次操作，每个 L2 交易要等待 24 个 CKB 确认再进行下一次操作，而 Jump 操作则需要等待 6 BTC + 24 CKB 确认。能否对这个方案进行优化呢？ 41 | ### **RGB 收款方 UTXO 的优化** 42 | 考虑原 RGB 协议，为了实现交易隐私性，Bitcoin 上发起的 RGB 交易的收款方（以一个 Bitcoin utxo 表达）和这笔 Bitcoin 交易的 output 并不一致。这使得观察者无法通过追踪 bitcoin 交易的方式来追踪 RGB 交易。 43 | 44 | 但在 RGB++ 协议中，所有的 RGB++ 层交易都同构绑定并公示在 CKB 上，尽管极大地简化了用户的交易验证难度，也较为遗憾地损失了 RGB 协议的隐匿性（RGB++ 协议可以利用 CKB 的隐私层引入[更为强大的隐私属性](https://forum.grin.mw/t/a-draft-design-of-mimblewimble-on-nervos-ckb/7695)）。所以 RGB++ 协议在收款人方面做了调整，它不要求收款方预先提供一个自己的 UTXO，而只需要提供一个收款地址，RGB++ 交易本身在构造 BTC 交易时会生成一个 UTXO 指向该收款人地址。这样就可以完成非交互式转账，大幅简化了用户的操作流程。注意下面的示意图做了一些简化，为了实现同构绑定，某些包含在 BTC TX 和 CKB TX 中的字段不会被包含在 commitment 中，以防止出现互相包含的矛盾。 45 | 46 | ![payee](./assets/sa-payee.png) 47 | 48 | ### **交易串接** 49 | 上面的 RGB 非交互式转账的优化不仅仅有利于提升用户体验，对于交易确认的优化也有本质的作用。 50 | 51 | ![sequencing1](./assets/sa-sequencing1.png) 52 | 53 | 首先对于一个诚实的用户，尽管区块 reorg 经常发生，但只要该用户不主动进行双花交易，BTC 链上打包的用户交易是不变的，因此不会影响到 CKB 链上的 RGB++ 资产和状态。 54 | 55 | 考虑一笔 L1 RGB++ 交易，假设为了用户体验我们允许单块 BTC 交易确认即可发起同构交易，即在 CKB 构造同步的 RGB++ 资产交易。此时，对于恶意用户，TA 可能构造一笔新的 BTC 交易，取代之前的 BTC TX B，使得 CKB TX B‘ 找不到对应的 BTC 交易，但这时 CKB TX B’ 已经上链。这里的后果是，在 BTC 上被双花的 btc_utxo#2 在 CKB 上的同构映射 cell 已经在 CKB TX B’ 中消耗了，即使用户双花了 BTC 上的 utxo，他也无法双花 RGB++ 的资产，同时先前交易生成的 RGB++ cell 输出（ lock 为 btc_utxo#3）也因为链式交易的失效而被永久锁定。所以恶意用户在 BTC 上做双花交易不会有任何收益，还会导致自己的资产失效。 56 | 57 | 考虑一笔 L2 RGB++ 交易，它 100% 运行在 CKB 上，因此我们只需要符合原来的交易逻辑即可，即也可以在 dapp 中获得连续操作的体验。 58 | 59 | 最后考虑一笔 Jump 操作，用户将 RGB++ 资产从一个 Bitcoin UTXO 中转到一个 CKB 地址上，后续的操作会持续发生在 CKB 上，此时我们需要考虑因 Bitcoin TX revert 造成的 CKB 上资产复制的问题。 60 | 61 | ![sequencing2](./assets/sa-sequencing2.png) 62 | 63 | 考虑上面的交易，BTC_TX_A 和 CKB_TX_B 同构绑定，之后 BTC_TX_A 被重构成 BTC_TX_A’，此时同构绑定的交易 CKB_TX_B’ 无法通过 ckb 共识上链，因为它依赖的 input (lock= btc_utxo#1)已经在 CKB_TX_B 中被使用了。这就导致 BTC 上的交易和 CKB 的交易同构绑定失败。但注意，如果同构绑定失败，但相关的所有资产均被锁定，那么我们不认为出现了安全性问题。因为这种失败源自交易发起人主观攻击协议，那么TA的所有资产被永久锁定不是问题。 64 | 65 | 但图示的操作中，我们发现 CKB 上的两个输出，RGB++ cell 的 lock 是 btc_utxo#2，它依赖被 revert 的旧的 BTC 交易，因此被永久锁定，没问题。单另一个 ckb cell 则不受影响。这就造成了安全风险。 66 | 67 | 因此，我们引入一个新的 lock，暂定名为 btc_time_lock 通过提供额外的锁定逻辑来解决这个问题。 68 | 69 | ### **BTC Time Lock** 70 | btc_time_lock 的核心参数有三个，分别是 lock_hash，after，和 bitcoin_tx。它具体的含意是：“仅当在参数中指定的 bitcoin_tx 被超过 after 个 btc 区块确认后，本 cell 才可以被解锁，且解锁后需要换成 lock_hash 指定的 lockscript(ckb 地址)”。 我们以上面的例子看一下 btc_time_lock 是如何工作的。 71 | 72 | ![time lock](./assets/sa-time-lock.png) 73 | 74 | 和之前的讨论相同，如果 BTC_TX_A 被 revert 了，对应的 RGB++ Cell 被永久锁定，而其他的 CKB cell 则按照要求被放置在 btc_time_lock 中，且他们被解锁的条件是 BTC_TX_A 经过了 6 个区块确认。那么显然由于 BTC_TX_A 不存在而因此被永久锁定。反过来讲，如果 6 个 btc 确认后，BTC_TX_A 仍然存在，那么该 CKB Cell 就可以正常使用。 75 | 76 | ## **总结** 77 | 总结来说，RGB++ 不论在 L1 还是在 L2 上都可以获得与 Bitcoin 相同级别的安全性，在 L1 和 L2 Jump 时，RGB++ 协议额外要求资产锁定 6 个或更多的 BTC 区块，以获得在跨层使用时一致的安全性。RGB++ 协议在不妥协安全性的前提下为 BTC 网络进行了图灵完备的补充和性能的扩展。 78 | 79 | ## References 80 | [RGB++ 深入讨论(1): 安全性分析](https://talk.nervos.org/t/rgb-1/7798) 81 | [直播回顾｜RGB++ 的前世今生](https://talk.nervos.org/t/rgb/7817) -------------------------------------------------------------------------------- /docs/security-analysis-en.md: -------------------------------------------------------------------------------- 1 | # A Deep Dive into RGB++: Security Analysis 2 | 3 | *Cipher from CELL Studio & Nervos Foundation* 4 | 5 | > Special thanks to [Ren Zhang](https://scholar.google.com/citations?hl=en&user=JB1uRvQAAAAJ), [Ian](https://github.com/doitian), and [c4605](https://talk.nervos.org/u/c4605/summary) for feedback and discussion. 6 | > The RGB receiver optimization approach is inspired by [Jason Cai](https://twitter.com/CryptoStwith). 7 | 8 | ## **PoW is More Secure Than You Think** 9 | The security concern in Proof-of-Work (PoW) lies in block revert/reorg which can enable double-spending attacks. Consider a network with an honest miner, a user’s status and assets would remain accurate, then only the block reorganization there could cause losses from double-spending. Consequently, the core security assumption of PoW is that transactions are highly unlikely to be reverted after N blocks. In Bitcoin’s case, 6 or fewer blocks are typically considered secure enough against double-spends. 10 | 11 | Obviously, Bitcoin transactions with 6 confirmations are more secure than 1 confirmation. So is there a linear relationship between the number of PoW confirmations and security? No, **the difficulty of overturning a block increases exponentially as the depth of the block increases**. The precise parameters of this exponential security growth have been analyzed in dozens of research papers. What has become clear is that “N confirmations” provide greater security than previously thought. 12 | 13 | According to calculations by Dr. [Ren Zhang](https://scholar.google.com/citations?hl=en&user=JB1uRvQAAAAJ), assuming that the adversary’s Hash rate accounts for 30%, CKB would need to maintain a 2.5% orphan block rate and require 23.29 confirmations to match the security of 6 confirmations on Bitcoin with a 0% orphan rate. This equivalence relationship provides a convenient way to discuss the security of various typical operations in the RGB++ protocol. 14 | 15 | ![pow](./assets/sa-pow.png) 16 | ***Schematic diagram of PoW security (non-theoretical calculation)*** 17 | 18 | ## **Security of RGB** 19 | RGB binds the status and contracts of RGB to Bitcoin UTXO using single use seals and client-side validation methods. This provides an extension of Turing-complete scalability for Bitcoin. There are two types of transaction security: 1) Correctness of state calculations, 2) Transaction certainty. Client-side validation ensures the correctness of state calculations. Everyone is responsible for their own state and does not rely on any third party. Single-use seals based on BTC UTXO ensure that the difficulty of double spending on RGB matches that of double spending on Bitcoin. Therefore, we can say that **RGB inherits 100% of Bitcoin’s security**. Users can achieve their desired security threshold by waiting for the corresponding number of Bitcoin confirmations. 20 | 21 | ## **Security of RGB++ Protocol** 22 | ### **L1 Transaction Security** 23 | L1 transactions for RGB++ refer to that the “holder” of UTXOs for RGB++ transactions is the holder of Bitcoin’s UTXOs. That is, only consuming Bitcoin UTXO can operate or update RGB++ UTXO. In this model, although each RGB++ transaction initiates a parallel CKB transaction, its security does not rely on CKB. CKB is only utilized for data availability and status disclosure purposes. Therefore, the L1 transaction security of RGB++, identical to RGB protocol, fully inherits the security of Bitcoin. 24 | 25 | ### **L2 Transaction Security** 26 | L2 transactions occur 100% on CKB, meaning CKB is responsible for 100% of L2 security. However,due to the non-linear security scaling of PoW chains previously mentioned, 24 block CKB confirmations provide equivalent security to 6 confirmed Bitcoin transactions. Therefore, we could believe that L2 transaction security matches L1 transaction security(more block confirmations needed but cost shorter time for the actual confirmation). 27 | 28 | The prerequisite for realizing this equivalent security is that the RGB++ isomorphic mapping chain must be PoW. If it were a PoS chain, its security upper bound would be limited by the staking amount of PoS no matter the number of confirmed blocks, which cannot compare to Bitcoin’s security. 29 | 30 | ### **Jump Operation** 31 | The RGB++ protocol enables users to seamlessly transfer their assets between Bitcoin and CKB in either direction at any time. There is no need for a cross-chain bridge during the switching process, and any reliance on multi-signature parties. This transition of assets or state between chains is called a Jump operation. 32 | 33 | Before and after the Jump operation, the core points that affect the security of the RBG++ protocol are: 34 | 35 | Single-use seals, from using Bitcoin UTXO to using CKB UTXO, or vice versa; 36 | Unchanged client verification data on CKB as they are the isomorphic binding transactions on CKB. 37 | During a Jump, users need to wait for sufficient block confirmations on both Bitcoin and CKB to to ensure the security. 38 | 39 | ### **Optimization of RGB Payee UTXO** 40 | Considering the original RGB protocol, in order to achieve transaction privacy, the payee of the RGB transaction initiated on Bitcoin (i.e. Bitcoin UTXO) is not consistent with the output of theBitcoin transaction. This makes it impossible for observers to track RGB transactions similarly to Bitcoin transactions. 41 | 42 | In contrast, in the RGB++ protocol, all transactions on RGB++ layer are isomorphically bound and published on CKB. Although it greatly simplifies user transaction verification, it, regrettably, compromises the anonymity of the orginal RGB protocol (the RGB++ protocol can leverage the privacy layer on CKB for [more powerful privacy attributes](https://forum.grin.mw/t/a-draft-design-of-mimblewimble-on-nervos-ckb/7695)). To address this, RGB++ adjusts the payee’s role, eliminating the need for the payee to provide their UTXO in advance. Only a payment address is required, as the RGB++ transaction will generate a UTXO pointing to the payee during a BTC transaction. In this way, non-interactive transfers can be completed, greatly simplifying the user’s operation process. Please Note that certain simplifications are made in the diagram below: to achieve isomorphic binding, some fields present in BTC and CKB transactions are excluded from commitment to prevent mutual inclusion conflicts. 43 | 44 | ![payee](./assets/sa-payee.png) 45 | 46 | ### **Transaction Sequencing** 47 | As outlined above, the optimization of RGB non-interactive transfers, serves a dual purpose by significantly enhancing user experience and playing a pivotal role in the optimization of transaction confirmations. 48 | 49 | ![sequencing1](./assets/sa-sequencing1.png) 50 | 51 | First, for an honest user, block reorgs on the BTC chain often occur but do not affect the validity of their transactions or associated RGB++ assets and status on the CKB chain, as long as they do not intentionally initiate double spending. 52 | 53 | Consider an L1 RGB++ transaction, for better user experience, we allow a single block of BTC transactions to be confirmed to initiate isomorphic transactions, that is, construct a synchronized RGB++ asset transaction on CKB. At this point, a malicious user could construct a new BTC transaction to replace a previous BTC TX B, which means that CKB TX B’ cannot find the corresponding BTC transaction. However, the new CKB TX B’ has already been committed to the CKB chain. As a result, the isomorphic mapping cell on CKB of btc_utxo#2 which was double spent on BTC has been consumed in CKB TX B’. Even if the malicious user successfully double-spend utxo on BTC, he cannot double-spend the corresponding assets on RGB++. At the same time, the RGB++ cell output generated by the previous transaction (lock is btc_utxo#3) is also locked due to the failure of the chain transaction. In summary, malicious users cannot benefit from BTC double-spends and will cause their own RGB++ assets to become unusable. 54 | 55 | For an L2 RGB++ transaction which runs 100% on CKB, we only need to comply with the original transaction logic. In other words, we can have a continuous experience within the dApp. 56 | 57 | Finally, consider a “Jump” operation where a user transfers RGB++ assets from a Bitcoin UTXO to a CKB address and subsequent operations continue on CKB. In this case, we need to consider the problem of asset duplication on CKB caused by Bitcoin TX revert. 58 | 59 | ![sequencing2](./assets/sa-sequencing2.png) 60 | 61 | Taking the above transaction, where BTC_TX_A on Bitcoin is isomorphically bound to CKB_TX_B on Nervos CKB, as an example. If BTC_TX_A gets reorganized as BTC_TX_A’, the isomorphic transaction CKB_TX_B’ cannot be validated through the CKB consensus, as it relies on the input (lock = btc_utxo#1), which has already been utilized in CKB_TX_B. Consequently, the isomorphic binding of transactions on BTC and CKB fails. Please note that if isomorphic binding fails while all related assets are locked, we do not consider it a security issue. This failure results from transaction initiator’s intentionally attacks, it should not be a problem that all his assets are permanently locked. 62 | 63 | But as shown in the above figure, there are two outputs on CKB. The lock on the RGB++ cell is btc_utxo#2. Since it depends on the old BTC transaction that has been reverted, there is no issue with it being permanently locked. However, the other CKB cell remains unaffected, which brings a security risk. 64 | 65 | Therefore, we introduce a new lock, tentatively named btc_time_lock, aiming to mitigate the issue by incorporating additional locking logic. 66 | 67 | ### **BTC Time Lock** 68 | There are three core parameters of btc_time_lock: lock_hash，after，和 bitcoin_tx. Its specific meaning is: “Only when the bitcoin_tx specified in the parameter is confirmed by more than after btc blocks, this cell can then be unlocked. After unlocking, it needs to be replaced with the lock script (CKB address) specified by lock_hash.” Let’s use the above example to see how btc_time_lock works. 69 | 70 | ![time lock](./assets/sa-time-lock.png) 71 | 72 | Same as the previous discussion, if BTC_TX_A is reverted, the corresponding RGB++ Cell will be permanently locked. The other CKB Cell is placed in btc_time_lock as required, with the condition for their unlock being the confirmation of BTC_TX_A by 6 blocks. Then, apparently, BTC_TX_A is permanently locked since it does not exist. On the other hand, if BTC_TX_A still exists after the confirmation from six BTC blocks, then the CKB Cell can function normally. 73 | 74 | ## **Summary** 75 | In summary, the RGB++ protocol provide a level of security equivalent to Bitcoin, whether having jump operations on Layer 1 or Layer 2. Jump between L1 and L2 requires the additional step of locking assets for six or more BTC blocks, ensuring consistent security approach when across layers. The RGB++ protocol complements the BTC network by providing Turing-complete functionality and enhanced performance without compromising security. 76 | 77 | ## References 78 | [A Deep Dive into RGB++: Security Analysis](https://talk.nervos.org/t/a-deep-dive-into-rgb-security-analysis-translation/7816) --------------------------------------------------------------------------------