CKB Eco Fund 宣布与 Cross-Chain Tokens（ccTokens）和 Meson Finance 达成战略合作，促成在 CKB 主网部署发行 1:1 比特币储备支持的 ccBTC。
其中，Cross-Chain Tokens（ccTokens）将在 CKB 主链上发行 ccBTC，为 CKB 主网引入比特币流动性。ccBTC 是一种由 1:1 比特币储备支持的代币，Cactus Custody 将作为 BTC 资产的官方托管人，确保对支撑 ccBTC 的比特币储备进行细致管理。Cactus Custody 是 Matrixport 的子公司，也是香港合规持牌的信托公司，遵守反洗钱和监管标准，提供安全高效的数字托管解决方案。
同时，Meson Finance 将作为 CKB Eco Fund 指定的跨链桥，正式上线 CKB 主网并支持 ccBTC，帮助用户实现 ccBTC 资产在主流公链及 BTC Layer 2 上的跨链流通。作为比特币生态中的领先跨链服务商，Meson Finance 已经覆盖了市面上所有的主流公链和二层网络，为用户提供包括 BTC、ETH 以及各种稳定币在内的主流资产跨链服务。
ccBTC 将利用 Nervos CKB 和 RGB++ 协议的特性，确保 BTC 在 Bitcoin 生态中安全地流动，助力各类 DApp 使用比特币资产，例如在 DEX、去中心化借贷、算法稳定币和衍生品市场，以及闪电网络、Nostr 社交协议等大规模采用场景。
从技术角度来看，ccBTC 是行业内首次在 BTC 主网以外的 UTXO 平台上发行合规托管的代币。储备金地址、余额和交易记录均可在 ccTokens 网站上公开访问和实时验证。项目在挖矿、销毁、链上验证等关键流程上采用多方确认机制，确保跨链资产服务透明可靠。ccTokens 的治理模式强调通过多机构框架、角色和权利隔离以及权力下放进行制衡，以防止潜在的不当行为。此外，黑名单机制支持持续的治理和合规工作。
此次战略合作不仅服务于 CKB 和 RGB++ 协议，更将为整个 Bitcoin 生态带来安全托管的 Wrapped BTC 资产，有利于激活沉睡的 BTC 资产。

关于 Nervos CKB
Nervos CKB 是领先的 BTC Layer 2，采用 Cell 模型和 PoW 共识机制，通过模块化架构来解决区块链可扩展性的难题，该架构将交易执行、共识和数据可用性分开。
关于 Cactus Custody
Cactus Custody 是 Matrixport 的子公司，也是一家香港信托公司，遵守反洗钱和监管标准，提供安全高效的数字托管解决方案。Cactus Custody 是机构级数字资产托管领域的领导者，为 300 多家知名客户提供支持，包括矿商、交易所和基金。
关于 Cross-Chain Tokens（ccTokens）
Cross-Chain Tokens（ccTokens）是挂钩代币，每个代币都以 BTC 等区块链资产 1:1 的比例支持。这些代币有助于将各种加密货币无缝集成到去中心化金融（DeFi）生态系统中。合格的第三方托管人或验证人全力支持和保护所有 ccToken。
关于 Meson Finance
Meson Finance 是基于 Atomic Swap 技术的去中心化跨链通道，支持 BTC、ETH 和稳定币在超过 50 条公链和二层网络上自由流通，旨在为用户提供安全、高效、低成本的跨链服务。

本文是 Messari 撰写的英文报告《Understanding Nervos Network (CKB): A Comprehensive Overview》的中文翻译版。本译文仅供参考，不具有法律效力。如有任何歧义，请以英文原文为准。我们已尽最大努力确保翻译的准确性，但不对因翻译可能造成的任何错误或遗漏承担责任。本报告的所有权利（包括但不限于版权、商标权和其他知识产权）均归 Messari 所有。本中文译文的发布已获得 Messari 的授权。在阅读、使用或传播本译文时，请遵守与原英文版相同的使用条款和限制。

摘要
#Nervos Network 在比特币的核心技术基础上进行了扩展，通过可扩展的一层区块链为#比特币 Layer 2 (L2) 提供支持。为了改善比特币的编程限制，Nervos Network 采用了一个定制的模型（Cell 模型）进行状态存储，以及定制的虚拟机（CKB-VM）来执行交易。Nervos 通过 RGB++ 扩展了比特币的可用性，RGB++ 是一个基于原始 RGB 协议的资产发行协议，旨在将 CKB 定位为比特币的执行层和数据可用层。自 RGB++ 协议在 #CKB 主网推出以来，CKB 网络的交易活动重新活跃起来，4月份新增了近40万个地址，环比3月增长了181%。将支付通道网络集成到闪电网络的工作正在进行中，这将使 CKB 更具可扩展性，并适用于各种区块链应用。
背景
作为最大的加密货币，比特币不断获得采用和认可。然而，它的成功也暴露出一些限制和挑战，特别是在可扩展性方面。例如，比特币区块链在 Segwit 升级之后，将区块大小限制在 4 MB 以内，这限制了在给定时间内能处理的交易数量。随着网络的增长，这种限制导致了更长的确认时间和更高的交易费用，使得比特币在处理大规模交易量时效率下降。与其他区块链相比，除了价值转移，比特币的脚本语言目前还缺乏开发复杂智能合约所需的灵活性和表现力。
为了解决这些限制，人们提出了多种 Layer 2 (L2) 解决方案，如支付通道、侧链和 Rollup。它们大多旨在通过在链下处理交易来扩展比特币，试图在不影响基础层安全性的情况下提高交易吞吐量。例如，闪电网络创建了一个二层支付通道网络，允许近乎即时的小额支付。另一种方法是侧链 — — 与比特币主链相连的独立区块链，拥有更大的脚本可能性和更快的交易。然而，这些解决方案往往有所取舍，如增加了复杂性、信任假设和潜在的安全漏洞。
Nervos Network 是比特币可扩展性解决方案之一，它采用了更原生的方式，修改了支撑比特币的 UTXO 模型。它改进了 RGB 协议，在无需跨链桥的情况下为比特币提供图灵完备的合约能力。Nervos Network 由 Terry Tai、Kevin Wang、Cipher Wang 和 Daniel Lv 于 2018 年第一季度立项，是一个旨在提高可扩展性的 Layer 1 区块链。为了推动网络的开发，项目团队从种子轮、私募轮和公募中筹集了超过 1 亿美元的资金。2019 年 11 月，Nervos Network 的 Layer 1 区块链 — — Common Knowledge Base（共同知识库，简称 CKB）上线。2024 年 2 月，由 Nervos 联合创始人 Cipher Wang 领导的 CELL Studio 推出了比特币一层资产发行协议 RGB++。受 RGB 协议的启发，RGB++ 协议使用 CKB 作为数据可用性和执行层，为比特币实现了智能合约能力和资产发行。自 2024 年 4 月 RGB++ 上线主网以来，利用 RGB++ 在比特币上发行资产的项目数量不断增加。截至 2024 年 6 月，现有的 15+ 个生态项目使 CKB 的链上活动重新活跃起来。
技术

Nervos Network 采用分层架构，包括一个可通过支付通道和 RGB++ 进行扩展的 L1 区块链（Common Knowledge Base，简称 CKB）。Cell 模型是比特币 UTXO 记账模型的改进版，CKB-VM 是一种定制虚拟机，它们支持了网络的分层设计。CKB-VM 为在网络上发起交易或构建应用提供了灵活的执行环境。这种设计可以让网络通过在每一层运行专用组件来进行垂直扩展，类似于模块化区块链。

Common Knowledge Base
CKB 是 Nervos Network 的底层 L1 区块链，其运行方式与比特币类似，采用工作量证明（PoW）共识机制。它使用比特币算法的升级版 NC-MAX，通过加快交易确认时间和降低孤块率来提高网络效率和响应速度。比特币以 10 分钟的区块间隔为目标，大约每两周调整一次挖矿难度。而 CKB 会根据网络活动的变化动态调整区块间隔（大约每四小时一次），从而优化性能。
CKB 使用了 Eaglesong 函数来确保网络的安全，这是一种 ASIC 中立的定制型哈希函数，可替代广泛使用的 SHA256 哈希函数。Eaglesong 是一种海绵函数，对多个加密元素进行了优化，可提供与其他工作量证明（PoW）哈希函数同等级别的安全性，同时专门为 Nervos Network 量身定制。
Cell 模型

Cell 模型是 CKB 数据结构的核心，可以在链上存储和验证任何数据。比特币原始的脚本语言和 UTXO 模型限制了其执行智能合约所需的复杂计算的能力。相比之下，CKB 对 UTXO 模型进行了一般化处理，允许更灵活的数据存储和验证。与使用单一脚本验证交易的比特币不同，CKB 在其 Cell 模型中引入了双脚本：
Lock Script（锁定脚本）确保只有授权用户可以访问和使用 Cell 中的内容，与比特币类似。Type Script（类型脚本）是可选的脚本，用于设定在未来交易中如何使用或更改 Cell 的规则。
与比特币的有限选项相比，这一系统使 CKB 能够支持更多的功能，使其更适合各种应用。CKB 中的每个 Cell 都是一个可编程 Cell ，可以保存不同的数据类型，如代币、智能合约和特定的应用状态。它还可以运行复杂的类似于图灵完备语言中的脚本。Cell 独立运行，这意味着它们可以在不影响区块链其他部分的情况下进行更新或引用，通过并行的方式提高可扩展性。

CKB-VM
CKB-VM 是 CKB 的执行引擎，用于运行智能合约和去中心化应用程序。该虚拟机使用 RISC-V 指令集，这是一种灵活、简单的开源硬件架构集（ISA），支持多种编程语言，包括 C 和 Rust 等流行语言。这种广泛的兼容性使 CKB-VM 有别于通常仅限于特定语言的其他区块链的虚拟机，向更广泛的开发者社区开放。CKB 网络还支持 JavaScript、Rust、Go 和 Java 等主流语言的 SDK，方便开发者使用熟悉的工具进行开发。这使得开发人员更容易使用熟悉的编程语言创建复杂的去中心化应用。
此外，CKB-VM 的架构提供了可预测的 gas 费用、安全的执行以及与 Cell 模型的高效集成，有助于有效管理状态和验证交易。可预测的 gas 费用模型避免了意外费用，提升了用户体验，并简化了合约开发。
RGB++ 协议

CKB 利用 RGB++ 协议扩展比特币，该协议是一种资产发行标准，可在 CKB 上扩展比特币的功能。RGB++ 协议可实现复杂的智能合约和资产管理操作，而这在比特币网络上通常是不可能实现的。最初的 RGB 协议是一个 L2 解决方案，目的是在不改变比特币主网的情况下，为比特币实现智能合约和资产发行。它通过将资产绑定到特定的比特币 UTXO，使这些资产可以随着 UTXO 本身的转移而转移。RGB 协议主要依赖客户端验证，交易在链下处理和验证，从而减少了比特币网络的负载。然而，这种方法也有局限性，比如数据可用性方面的潜在问题 — — 由于数据不存储在链上，因此在需要时可能无法随时访问。此外，对客户端验证的依赖增加了复杂性，可能会影响用户体验。

Nervos Network 通过 RGB++ 协议解决了这些限制，该协议通过使用 CKB 作为比特币的数据可用性和执行层，扩展并增强了原始 RGB 协议背后的原理。RGB++ 通过同构绑定技术，将比特币 UTXO 映射到 CKB 的 Cell 上，实现了与 CKB 图灵完备智能合约的无缝集成。这是通过利用 CKB 的分层架构和 Cell 模型实现的，允许比特币资产与 CKB 上的 dApp 进行交互。通过使用 RGB++，CKB 可以为比特币执行更复杂的智能合约，而这在最初的 RGB 协议中是不可能实现的。RGB++ 还引入了关键交易元素的链上验证，提高了安全性和数据可用性。此外，RGB++ 协议还能实现交易折叠、共享状态的无主合约以及非交互式转账，且无需跨链桥即可实现比特币的跨链转移。

支付通道

作为底层公链，CKB 可以通过支付通道进行扩展，比如 Polycrypt 开发的支付通道框架 Perun。通过在链下处理交易和链上结算，这些支付通道可以支持从小额支付到支付网关等多种应用，从而提高 CKB 的性能。Perun 利用了 CKB 的 Cell 模型，其中 Cell 携带了 capacity、Lock Script、Type Script 和数据来管理通道的状态。通道的其中一个实现（PerunLockScript）可以管理通道实时 Cell 的访问权限，而另一个实现（PerunTypeScript）可以处理状态转换的验证逻辑。从通道获得资金到关闭，这些转换都是自动管理的。截至发稿时，Perun 仍在测试中，尚未在 CKB 主网上线。Nervos 核心开发人员还在努力将 CKB 连接到比特币的闪电网络，使用户能够在不依赖第三方的情况下交换 BTC 和 CKB。
代币经济学
Nervos Network 的原生代币 CKByte（CKB）在维护网络安全和激励有效存储方面发挥着重要作用。CKB在网络中的主要作用包括：
授予代币持有者数据存储权。作为链上交易的手续费。作为区块奖励发放给矿工，以确保网络安全。
此外，CKB 代币有三个来源：（1）创世区块；（2）基础发行；（3）二级发行。
创世区块
2019 年 11 月主网启动时，创世区块铸造了 336 亿枚 CKB 代币，其中 84 亿枚 CKB 代币（占初始发行的 25%）被立即销毁。在销毁的这84 亿枚 CKB 中，50.4 亿枚代币被用于链上存储（”占用链上空间”），剩余的 33.6 亿枚代币处于流动状态（”流动性”）。对这些被销毁的代币进行相应的状态分配，目的是为了让矿工在最初时至少能获得二级发行的 15%，而国库基金至少能获得 10%。值得注意的是，目前分配给的国库基金的 CKB 代币全部被销毁，只有通过网络硬分叉才能更改此设定。

创世区块中的 CKB 分配如下：

公募（~21.50%）：创世区块的最大部分在 2018 年提供给了公募投资者，并在 2019 年 11 月主网启动时全部释放。生态基金（17.00%）：生态基金将支持 Nervos 生态系统内的第三方开发者。在创世区块的计划中，这笔拨款的 3% 主网启动时已经到位，其余部分将在两年内发放，到 2022 年 12 月结束。团队（15%）：预留给项目团队，在 2022 年 5 月结束四年的锁定期。私募（14%）：于 2018 年 7 月提供给私募投资者。其中 66.60% 在主网启动时释放，其余部分在 2020 年结束两年的锁定期。合作伙伴（5%）：这笔拨款是为帮助建立 Nervos Network 的战略合作伙伴预留的，锁定期是四年。测试网奖励（0.5%）：这些奖励在主网启动时全部分配给测试网和漏洞赏金计划的参与者。销毁（25%）：在创世区块中，这部分直接销毁，以保证矿工和国库基金持续获得二级发行。

基础发行

CKB 基础发行（一级发行）的目标是在网络的早期发展阶段提升网络的安全性。每个 Epoch 的 CKB 基础发行量固定，全部奖励给矿工，奖励他们处理网络上的交易。基础发行的上限为 336 亿枚 CKB 代币，并遵循与比特币类似的通胀时间表，即每四年减半一次，直至达到供应量的上限。2023 年 11 月，CKB 经历了首次减半事件，基础发行的年发行量从 42 亿枚 CKB 降至 21 亿枚。

二级发行
CKB 通过两种方法管理状态爆炸。首先，要在链上存储数据，用户必须锁定 CKB 代币。CKB 并不直接向锁定 CKB 代币的用户收取费用来支付状态租金，而是通过一种称为二级发行的通胀机制间接收取费用。每年，13.44 亿枚 CKB 代币通过二级发行被铸造出来，并分配给矿工、Nervos DAO 储户以及国库基金。因此，二级发行针对存储数据的用户引入了通货膨胀，因为锁定的 CKB 代币会自动面临价值稀释，这是支付状态租金的一种间接方式。截至写文，已有超过 6 亿枚 CKB 代币作为状态租金分配给了矿工，约 11.5 亿枚 CKB 代币奖励给 Nervos DAO 储户，分配给国库基金的超过 42.7 亿枚 CKB 代币被直接销毁。
Nervos DAO
通过 Nervos DAO，CKB 代币持有者可以原生地避免被二级发行所稀释。通过将持有的 CKB 代币锁定到 Nervos DAO 智能合约中，用户可以从二级发行中获得代币奖励，确保其持有的代币免受通货膨胀的影响。Nervos DAO 储户获得的收益率与二级发行的通胀率相同，随着总供应量的增加，APR 也会继续下降。用户可以随时往 Nervos DAO 存款，最低金额为 102 CKB，但取款只能在 30 天存款周期结束后才能进行。

截至写文，已有 92 亿枚 CKB 代币存入 Nervos DAO。CKB 的存入流通比为 20.84%，在过去两年中一直呈下降趋势。这种下降趋势可能是因为 CKB 上的未花费 Cell 数量不断增加。

网络活动

在过去的一年里，CKB 网络持续活跃。截至目前，CKB 的日均交易量为 43,600 笔。与 2023 年第四季度的日均 20,800 笔相比，增长了 110%。在新增地址方面，4 月份的链上活动明显增加。4 月份创建了 387,600 个新地址，与 3 月份相比，环比增长了 181%。

自 4 月份以来，CKB 上的 Cell 活动一直在稳步增加，部分原因是 RGB++ 协议的推出。Cell 活动分为未花费 Cell 和已花费 Cell。未花费 Cell 可用于未来的交易、智能合约执行和数据存储，反映了网络活动和采用率的提高。已花费 Cell 虽然不再用作交易输入，但仍包含可访问和引用的有价值数据，有助于区块链的历史和数据可追溯性。截至 2024 年 5 月 15 日，共有 170 万个未花费 Cell ，与第一季度末相比增长了 13%。至于已花费 Cell ，截至发稿时，CKB 上共有 5760 万个已花费 Cell 。

自 RGB++ 协议于 2024 年 4 月 3 日上线以来，已有超过 13,200 笔交易和 4,400 个独立地址使用该协议。整个 5 月和 6 月的网络活动呈下降趋势，但利用 RGB++ 的更多生态项目应该有助于扭转这一趋势。

安全性与去中心化
作为 PoW 网络，矿工通过解决加密难题来验证交易并向区块链添加新区块，从而确保 CKB 的安全。每挖出一个区块，矿工就能获得该区块的全部 “基础发行” 奖励和部分 “二级发行” 奖励。矿工还可以从处理网络交易的交易费中获得提案奖励或提交奖励。为了在不降低性能的情况下管理网络活动的变化，CKB 定制的 NC-MAX 共识协议大约每四个小时根据网络的孤块率调整一次挖矿难度。这样，网络可以优化出块时间，同时降低区块重组的可能性，因为区块重组可能会破坏网络的稳定性。

算力是对 PoW 区块链矿工基础计算能力的衡量标准。因此，算力代表着 CKB 网络的安全性。2024 年，CKB 全网算力不断刷新历史新高。4 月 27 日，CKB 的全网算力达到 397.5 PH/s，是 CKB 网络有史以来的最高算力值。算力上升的部分原因是 Binance 于 2024 年 4 月 18 日开启了 CKB 矿池。与算力类似，2024 年的平均挖矿难度也创下了历史新高（4 月 21 日该值为 3.96E）。

生态系统
Nervos Network 继续通过资金、基础设施和工具支持来促进生态系统的发展。在 2019 年 11 月主网上线时，约 57 亿 CKB（占创世区块 CKB 分配额的 17% — 写文时为 6240 万美元）被预留用于生态基金。多年来，生态基金已为多个生态发展计划提供了种子资金，以推动网络的发展计划。其中之一是 CKB Eco Fund（前身为 InNervation），该生态基金专注于孵化和投资使用 RGB++ 连接 CKB 和比特币的早期和种子轮项目。CKB Eco Fund 支持生态项目建设关键的基础设施和跨领域的去中心化应用，包括 DeFi、游戏、工具、NFT 市场等。2024 年 1 月，CKB Eco Fund 推出了 BTCKB 计划，旨在通过 PoW 共识机制和 UTXO 模型加强比特币和 CKB 区块链之间的集成。BTCKB 计划引入新的智能合约功能，将 BTC、Taproot Assets 和 RGB++ 资产纳入到 CKB 区块链中，从而增强比特币区块链的功能。作为该计划的一部分，CKB Eco Fund 还孵化了 CELL Studio，这是一家由 Nervos 联合创始人 Cipher Wang 领导的区块链软件公司，也是 BTCKB 计划的牵头者。CELL Studio 开发基础设施和应用程序，以增强和扩展 Nervos 生态系统，它与 ConsenSys 为以太坊开发 Infura 和 MetaMask 等基础工具的方式类似。截至目前，CELL studio 开发的知名生态系统工具包括：
CoTA：CKB 上 fungible 和 non-fungible token 的聚合协议。ForceBridge：连接 CKB 和其他区块链网络的跨链互操作性协议，目前支持以太坊和 BNB 智能链。Spore：由 CKB 支持的链上数码物（DOBs）协议。
自 2024 年 4 月 RGB++ 主网上线以来，已经有超过 15 个现有生态项目利用该协议进行资产发行。值得重视的生态项目包括：
UTXO Stack：基于 RGB++ 协议的比特币 L2 “OP Stack”。JoyID：非托管钱包，利用生物识别技术进行用户身份验证，支持多个网络，包括以太坊、比特币和 RGB++ 资产。HueHub：去中心化交易平台和 launchpad，支持比特币上的 RGB++ 资产。Stable++：去中心化的稳定币协议，支持 CKB 和 BTC。World3: 基于 RGB++ 协议和 DOB 的自主世界游戏。Nervape：基于比特币的多链可组合数码物，其 “基础资产” 在比特币上发行，“附属资产” 在 CKB 上发行。Haste：RGB++ 资产管理解决方案。d.id：比特币生态的去中心化身份协议。
CELL Studio 发布的 RGB++ 开发路线图强调了 2024 年内要完成的重要计划包括：
发布一个跨 UTXO 链发行 RGB++ 资产的跨链协议。通过 RGB++ 协议将 Atomicals、Orderals 和其它基于 UTXO 的资产无桥跨链到 CKB。提出并实施支持多网络的 RGB++ 扩展解决方案。将 RGB++ 与 CKB 闪电网络连接起来。
作为 BTCKB 计划的一部分，CKB Eco Fund 还打算推出连接 BTC 和 CKB 的跨链桥和基于 UTXO 的 DEX。此外，还会利用 RGB++ 协议为 CKB 开发了一个支付通道网络，相关的概念验证已完成。该支付通道网络将连接到闪电网络，使 CKB 更具可扩展性，适合各种区块链应用。
竞品分析
作为比特币 L2，Nervos Network 扩展比特币的方法主要是通过 RGB++ 协议来增强比特币的功能。像 Stacks 这样的竞品提供了定制的执行环境和编程语言，而 Rootstock 则对两条链之间的交易进行挂钩。相比之下，Nervos 的目标是在不增加复杂性或损害去中心化的情况下增强原生的比特币体验。借助 RGB++ 协议，CKB 可以为比特币提供与比特币原始 #UTXO 模型紧密结合的智能合约执行环境。这种设计可能会为 Nervos Network 带来优势，吸引那些对偏离比特币核心理念 —— 去中心化和安全性 — — 的解决方案持怀疑态度的用户

与闪电网络这样的扩展解决方案相比，CKB 的智能合约提供了更广泛的功能，可为开发者在比特币上构建更复杂的应用程序提供服务。虽然闪电网络能有效促进快速、低成本的交易，但它并不支持复杂的去中心化应用。与此同时，Liquid Network、Merlin Chain 和 Bouncebit 等平台需要信任半中心化的联盟来管理侧链与比特币主网之间的跨链桥。CKB 使用链下计算和链上结算的方法，避免了这种程度的中心化。
尽管如此，Nervos 利用 RGB++ 协议扩展比特币的方法并非没有局限性。在数据可用性和资产发行方面对外部网络（特别是 CKB 区块链）的依赖，为比特币带来了额外的复杂性和潜在的延迟。此外，由于缺乏全面的开发工具和多方交互解决方案，限制了该协议有效支持去中心化应用的能力。最后，CKB 区块链上交易的透明性损害了 RGB 协议最初提供的隐私优势。

总结

随着人们对比特币原有功能之外的可扩展性和功能的需求不断增长，比特币 L2 市场也在持续发展。各种 L2 解决方案，如闪电网络、侧链和 Rollup，旨在通过将交易移出主链来解决这些问题，从而在不影响安全性的情况下提高比特币的吞吐量。然而，这些解决方案往往会带来新的复杂性和安全挑战。Nervos 的与众不同之处在于通过 RGB++ 扩展了 RGB 协议。RGB++ 为比特币提供了原生扩展，集成了与比特币 UTXO 模型直接相关的更深层次的智能合约功能。这些功能反过来又促进了比特币实用性更加无感、更加安全的扩展。此外，将支付通道网络与闪电网络连接在一起的工作正在进行中，这将使 CKB 更具可扩展性，适用于许多区块链应用。
最终，Nervos 的目标是通过简化用户和开发者体验来加强其在比特币 L2 领域的地位。此外，Nervos 还可以优先为更广泛的资产类型和复杂应用提供 RGB++ 支持，从而提高其在比特币生态系统中的实用性。通过这样做，Nervos 可以在比特币作为去中心化应用和智能合约平台的更广泛采用和功能性方面发挥关键作用。

6 月 10 日，RGB++ 协议作者、CELL Studio 创始人 Cipher，DotSwap 联合创始人 Lin，Shell Finance 联合创始人 Tim Xie，以及 TBC（Turingbitchain）的 CMO NIGO 做客 UTXO Stack 的推特 Space，畅聊 UTXO 模型能否催生比特币生态新模式。
在上一篇文字整理稿中，嘉宾们分享了 UTXO 模型和账户模型在设计哲学、效率等方面的区别和优势，以及如何在 UTXO 模型的基础上实现智能合约能力。这篇文字整理稿将涵盖基于 UTXO 模型开发项目的挑战、L2 解决方案、安全性、生态模式等话题。

3、基于 UTXO 模型开发项目，你遇到的最大挑战是什么？
Cipher：前面我们讲了 UTXO 模型的优势，比如简洁、并发、调试更方便等，但其实它的缺点也很明显，比如说它的全局状态会比较麻烦。

以太坊账户模型的全局状态更新实际上是由矿工来做的，把交易加入区块的同时，计算了全局状态的更新。但是 UTXO 模型的全局状态只能是在链外发交易的人更新完这个状态，然后 commit 出去。这里面就遇到了一个问题，如果某个 UTXO 保存了所谓的全局状态，那似乎就代表在同一个区块里面只能有一个人去更新它。如果两个人同时更新它的话，那就冲突了。
我们在实际的开发工作中，大量的工作会在这上面产生，就是我们需要一个链外的 Aggregator 把很多人对于全局状态的访问聚合起来，聚合成一个单一的结果，然后上链，区块链只处理最终的那个状态的迁移，这等于是账户模型和 UTXO 模型相结合的思路。这实际上就是我们认为最大的技术挑战了，它增加了很多的开发工作量。相对于账户模型来讲，除了常规的链上智能合约和链下访问接口之外，你还要做一个链外的聚合操作和计算的接口，链外计算和链外聚合会带来很多工作量。
当然，我们也有解决方案，我们尝试在 L2 也把矿工也引进来，可能不一定叫矿工了，叫 L2 节点比较合适，它们同时承担 Aggregator 的工作，当然这里面也需要一部分的开发。
我们有一个兄弟项目叫 Khalani，他们有一个思路，他们用一种形式化语言来在这个 RISC-V 的 VM 上又搭了一层 VM，这个 VM 是处理刚才讲的这个形式化语言的。那这个形式化语言能做什么事情呢？当你写一个面向 UTXO 的智能合约的时候，它会自动地同时生成链外的 Aggregator 和 Generator，通过这种方式实现编写一次代码，生成多个处理器。这个思路其实也非常酷，当然他们也还没有开发完成，这里面技术难度挺大的。
Tim Xie：如果用个比喻的话，我觉得以太坊那边其实是一个高度细分的流水线工厂，你想做任何事情，无论开发还是知识的获取，都相对比较容易，生态也非常丰富，基建、中间件的支持和方案也都有。当你回到比特币生态的时候，就像从工业社会回到农业社会，就像在福特开发出流水线之前，如果你生产汽车，可能你既要去造轮子，你还要去造制造轮子的这样一个工具。比如说我们在做 Shell Finance 的时候，需要一个 oracle，需要用到 DLC，但市面上没有可用的 DLC，我们只能自己去做，去跟别人合作一起开发。这就好比以太坊上的 MakerDAO 做稳定币的时候需要一个 oracle，但市面上没有 Chainlink，他们只能自己去做 Chainlink。
所以，从我的角度看，在比特币生态开发最大的困难在于生态支持，以及基于 UTXO 开发的难度要比基于 EVM 开发的难度大很多。当然，这也是必须要经历的一个阶段，一个生态的早期参与者就是要比后来者背负更多的压力、解决更多的问题。
4、目前市场上有哪些基于 UTXO 模型的 L2 解决方案，它们如何解决比特币的可扩展性问题？

Lin：如果严格按照我之前讲的判断标准，那一个都没有，因为它们的交易都没有发在 L1 上面。换句话说，在比特币一层上面，我们还可以有一些叠加层，这些叠加层去执行一些新的规则，这些新的规则只在叠加层生效，不在一层上面生效，但同时这些叠加层又享有一层的好处，比如说 UTXO 的防双花机制等。这其实是我个人的看法，所以我目前没有把那些所谓的比特币 L2 项目当作二层。

广泛意义上的基于 UTXO 模型的 L2 项目，我看的比较少，我主要在研究如何用 ZK（零知识证明）的方式做 trustles bridge，发挥 UTXO 的优势。目前市面上的跨链桥，大部分都是偏中心化的方式，把资产从一条区块链跨到另外一条链，在我看来，无论是严格意义上还是广泛意义上，都不能算 L2。（注：这里推荐阅读《RGB++ 资产为什么可以实现无桥跨链》）
5、有人担心引入一些复杂协议可能会对比特币的安全性和共识机制带来挑战，大家怎么看？
NIGO：Ordinals 和 BRC-20 确实带来了很多争论，这些争议可以分成两大阵营。支持方认为，只要你支付手续费，你就有权利以任意的方式使用区块空间，不论交易的是什么内容。他们认为，BRC-20 和 NFT 给比特币带来了新的文化和叙事，有利于提高比特币的实际应用价值。而 Core 开发组其实是比较反对的，他们认为比特币主链要保持简洁，让 BTC 作为数字黄金，不希望它去做什么应用，所以他们认为 BRC-20 与 NFT 是毫无价值的垃圾交易，而且过多垃圾交易还会抢占交易带宽，导致交易入块时间变长以及手续费变高。所以本质上还是理念的不同。
我个人觉得比特币 UTXO 加上默克尔树的底层模型，天然适合高并发、高性能的交易，如果主链的 Core 开发组不支持，那我们就来到二层甚至侧链去实现。我比较认可 “you play you pay”，只要你付钱了你就可以玩，我相信在座的各位都属于支持方。
Lin：我觉得大家可以思考一下，别人说引入一些复杂协议可能会对比特币的安全性和共识机制带来挑战，那这个挑战到底是什么？不能别人说会带来挑战，我们就信了，对吧？以及这个挑战假设它发生了，我们作为个人，作为比特币的支持者，要通过什么样的去中心化的方式来保护我们的比特币资产不受影响？这些问题其实很值得思考。它其实是回到了去中心化的本质。既然讲去中心化，那就肯定不是某些人的看法，而是要在这个事情上能够达成共识。那么我们大家在这里面共识达成的机制是什么？这挺有意思的，我不想直接给一个我自己的看法。
我还想抛出这么一个问题，如果有人提出来说某些协议、某些应用对比特币的安全有影响，OK，那不管是我们自己是支持还是反对这样的观点，我们能够用什么样的方式去表达，去保护自己手里的比特币资产呢？我们是怎么保护的呢？这些值得大家去想一下。
Tim Xie：我最近一直在看比特币的全网算力和矿工收入能否覆盖其支出。比特币的区块奖励会大约每四年减半一次，越往后越少，而矿工只以利益为主，区块奖励变少了之后，矿工们凭什么去维护网络的安全呢？他们投入算力是一定要有回报的。所以很明显，如果比特币系统要持续运行下去，它的发展路径一定是链上的交易越来越多，生态越来越繁荣，矿工费变得足够丰厚。
Ordinals 和 BRC-20，它们并没有去分叉比特币，也没有影响比特币的共识和安全，它们是靠 Indexer 的方式去扩容的，在比特币主链上就是一笔 UTXO，只不过它比较麻烦而已。在我看来，它们并没有损害整个比特币网络里面最核心的价值——这个网络本身，也没有植入任何病毒。
相反，Ordinals 和 BRC-20 等新协议，给比特币带来了新的可能性，带来了一批新用户，并让一部分用户留在了比特币生态，同时还增加了矿工 的手续费收入，为比特币系统持续运行下去作出了贡献。
6、UTXO 的独特性能否催生新的生态模式，有哪些项目值得关注？
Cipher：比特币生态从铭文开始火起来，然后大家开始谈比特币文艺复兴，现在整个生态进入到了一个蓄势待发的阶段，我觉着这里面有一个很大的契机是以太坊生态遇到了瓶颈。
过去比特币被认为只要做好 SoV（价值存储）就好了，不用做别的。以太坊是世界计算机，我们要把去中心化世界的理想搭建在以太坊上，去中心化的媒体、金融应用、游戏等等，都搭建在以太坊上。但随着以太坊越来越固化，资本局越来越重，新的创业者机会越来越少，以及从 PoW 转向 PoS，大家开始怀疑说我们是不是真的应该把未来的 Web 3 设施都压在以太坊上。同时，像 Solana 这样的新兴平台也在崛起，它不在乎去中心化，甚至名牌说自己偏中心化，但效率就是高，就是快，就是便宜，在不断地抢以太坊的市场。
这个时候，有一帮人说，我们反而认可最早期的比特币，它更去中心化，更精简，我们要在比特币生态重构整个去中心化基础设施。这个叙事更让人感兴趣，也有它的独特之处，但跟 UTXO 的关联没有那么大。换句话说，这里面其实是价值取向的不同，而 UTXO 只不过是因为它的优势在这个叙事中逐渐凸显出来了而已。
另外，以太坊的生态发展一方面也在向 UTXO 这边靠拢，比如说并行 EVM 的计算，就是在每笔交易发起的时候，先明确标出来我会消费或者占用哪些状态，这样的话方便我去做并行处理，这其实就是 UTXO 的思想。
在 DeFi、NFT、元宇宙等领域，有哪些创新项目值得关注？我对 CKB 生态更熟悉一些，像 Nervape、Unicorn 这些项目，它们跟以前的 PFP NFT 项目不一样，它们更强调互动、游戏性、内部参数的变化，更像 Loot。
此外，我比较看好闪电网络，它是更适合 UTXO 的，以太坊世界基本上就没有出现过闪电网络。基于闪电网络的支付，基于闪电网络的各种 Finance，这块肯定是一个大的赛道，会有新的东西出来，只不过目前技术还没有那么成熟，但其实会发展很快，可以期待一下。
Tim Xie：我认为目前以太坊还是创新领域里面走在最前沿的，只不过它遇到了问题。以太坊白皮书里描绘的东西，包括预测市场、交易、DeFi、预言机、RWA 等，基本上都做完了，所以下一个阶段它要做什么，其实它是不知道的。没有新的需求出现的时候，大家会陷入到集体性的迷茫，需要独自地去闯出一条路来。
目前市场的反应是两条不同的分支路线，一条是 Solana 说的我们要去搞 AI，去搞 DePIN，另一条是一部分用户觉得我们要回到比特币这边。现在比特币生态在做铭文，在做 DeFi，我们的意识形态其实还是在按照以太坊的范式往前走，所以前期的生态发展基本都是一样的。
等比特币这边走完了这一阶段，可能是一年、两年或者三年之后，比特币生态会不会开始变得和以太坊生态不一样呢？从目前来看，比特币这边有资本也有能力去做这样的事情。不过这边的问题是非常去中心化，不像以太坊有基金会去统一地组织和协调。当然这有利也有弊。有利的一面是大家可以探索各种各样的可能性，不会受到别人的约束，也不用去管什么正统性，大家都可以尽自己的技能去探索。我目前的看法是，在可预知的两年内，我们其实是一个追赶的角色，把曾经以太坊行发生过的事情以及被验证过成功的模式，在比特币这边重新做一遍。两年后，当我们已经追赶完了之后，我们要怎么走才是一个非常重要的问题。
Lin：我个人的想法是，如果我们把比特币当作数字黄金，那在比特币上的各种资产可以看作是黄金艺术品。黄金艺术品不一定要用黄金去购买，也可以用法币或者其他货币去购买，同理，比特币上的资产也不一定要用比特币去兑换。
现在比特币 ETF 已经通过了，所以我们要开拓视野，不是所有东西都要追求链上交易，我们也不应该只盯着了解比特币知识、拥有比特币的那一小部分人群，这其实是不对的，因为这个市场非常的小。也就是说，我们要开拓视野，要出圈，走向更广阔的市场。

6 月 10 日，RGB++ 协议作者、CELL Studio 创始人 Cipher，DotSwap 联合创始人 Lin，Shell Finance 联合创始人 Timxie，以及 TBC（Turingbitchain）的 CMO NIGO 做客 UTXO Stack 的推特 Space，畅聊 UTXO 模型能否催生比特币生态新模式。

UTXO Stack 是模块化的 BTC L2 一键发链平台，可以帮助项目开发者一键发行基于 UTXO 架构的比特币 L2，并且原生集成了 RGB++ 协议。在安全性上，UTXO Stack 通过质押比特币、CKB 以及比特币 L1 的资产来保证 L2 的安全。简单来讲，我们可以把 UTXO Stack 想象成比特币生态的 OP Stack + EigenLayer。
UTXO Stack 已经完成种子轮融资，由 ABCDE 和 SNZ Capital 共同领投，OKX Ventures、Waterdrip Capital、Matrixport、y2z Ventures、DRK Lab 和 Bitcoin Magazine 母公司 BTC Inc 风投部门 UTXO Management 等多家知名机构跟投。
以下是根据音频整理的重点内容：
1、UTXO 模型和账户模型在设计哲学、安全性、效率等方面，有什么本质的区别和优势？
Cipher：我觉得主要是设计哲学和效率有一些区别，安全性可能更多的还是看共识机制，和账户模型关系不大。
设计哲学上，UTXO 其实更偏验证，而不是偏计算。我们知道以太坊的账户模型，你去写程序或者发交易的时候，你并不知道这个交易结果，你发的是一个动作或者是一个函数调用，那至于这个调用的结果是什么，只有交易被打包成区块之后你才知道结果。
典型的例子是，假设你的账户里面只有 0.1 个 ETH，能不能发一笔往外转账 0.2 个 ETH 的交易？可以的，你发出去，但是这笔交易可能进交易池之后，它会被打包，然后返回错误，因为你没有这么多钱，但是你的 gas fee 还是会被扣掉。但是如果你发送的同时，刚好有人给你账户上转了一笔钱，使得你的账户余额超过 0.2 个 ETH，那你这笔交易就成功执行了，当然也要扣 gas fee。
但是对于 UTXO 模型而言，你这笔交易就发不出去，因为你账户钱不够，你凑不出来足够的 input。所以在 UTXO 模型下面不存在交易失败这种状态，它只存在交易成功或者发不出去这两种状态，即所谓的交易失败是验证不通过，也不会扣你的手续费。UTXO 更认为区块链就是个验证机器，而不是计算机器，而采用账户模型的以太坊曾经有一个外号叫世界计算机，它是要计算的，完全是不同的设计哲学。
效率方面两者也有非常大的区别。UTXO 明确地指出之前使用的是哪些状态，然后把它销毁掉，更新成新的状态。而以太坊在函数调用的时候，并不知道在调用之前它会访问哪些状态，所以它只能按最差情况处理，就是对所有的状态都不做预处理。因此，以太坊每一笔交易只能串行执行。普通的一台桌面电脑，它的 CPU 至少是六核 12 线程，但是对于标准的 EVM 来说，仍然是单线程去执行。而 UTXO 不同， UTXO 天然就是并行的，它的所有交易都是自动可以区分哪些交易是冲突的，甚至冲突的交易都不会发到交易池里面，因此 UTXO 区块链的效率明显高于账户模型。当然现在有一个叙事叫做并行 EVM，想用某种形式解决这个问题，但是从刚才的描述大家也能意识到这不可能从本质上解决。

Tim Xie：我很认同刚刚 Cipher 讲的 “比特币 UTXO 模型更偏验证，以太坊的账户模型更偏计算”。在 DeFi Summer 的时候，我们去做一些 swap，以太坊的 gas fee 会很高，虽然相比于比特币，以太坊的出块速度更快、区块更大、性能更好，但以太坊对于扩容的需求其实比比特币还要更高。为什么呢？原因在于以太坊是一个计算模型。我们玩 DeFi，支付的 gas fee，可能有 98% 都是花在计算上，在验证、传播和存储账户状态这部分的花费其实是非常少的。比特币是一个验证网络，它不做计算，所以我们在比特币二层上做 lending 或者 swap，同样的场景下，手续费反而比以太坊那边还要便宜。
第二个是并发。EVM 为什么是串行的，刚刚 Cipher 解释得非常清楚，UTXO 则可以做并发，这点在做业务上会带来什么差异点呢？在以太坊上做 lending，你需要先存款然后才能借款，因为业务逻辑是你要有抵押物，要先等抵押的这笔交易确认了，状态固定了，它才可以去计算你的抵押物净值和清算阈值，让你借款，这一切是串行的。而 UTXO 可以做并发，我们可以把所有的交易尽可能压缩在一起，这意味着可以把用户的存款交易和借款交易合并成一起，提高效率。
从我们的感受上来讲，在比特币上用 UTXO 模型做 DeFi，最后给用户带来的体验其实并没有人们想象中那么的差，虽然体验不如以太坊或者 Arbitrum 上的应用那么丝滑，但也不会太差，还是可以用的。
Lin：我做一个补充。现有的技术在不断地演进，我认为 UTXO 不是不做计算，它同样也是可以做计算的。比如大家最近热议的比特币操作码 OP_CAT， 如果启用，我们就可以在比特币的 UTXO 中保留状态。如果我们把各种比特币原生的限制都拿掉的话，我们可以在比特币的 UTXO 中去模拟无数个以太坊，每一个 UTXO 都可以是一个以太坊的状态，然后把数据和执行在这个状态当中进行延续，从而使这个状态一直往下推演下去，虽然这样不一定能做到完全的 EVM 兼容。
所以我认为比特币一样可以做计算，而且比特币的逻辑是你随时可以开新的线程，你随时可以分裂出一个新的 UTXO，新的 UTXO 和原来的 UTXO 完全切割开来，这是比特币 UTXO 在计算上的一个特点。
加入 OP_CAT 之后，将会带来很巧妙的一些应用场景。比如说，以太坊 ERC-20 代币会维护一个列表，可以知道哪些账户有多少钱，加入 OP_CAT 之后，在比特币上我们也可以做类似的事情，甚至可能比以太坊做得更好。
在 UTXO 当中，数据共享其实是一个很大的未知的空间。比如说 Covenants（限制条款），现在还需要一段时间的建设，等这个事情往前推进了以后，在不同的 UTXO 当中如何实现共享数据，在交易当中如何引用交易之外的数据等等，或许会有突破。
NIGO：我一直认为以太坊把比特币的 UTXO 模型改成了账户模型，其实是典型的画蛇添足，而且把本来能够进行并发的系统变成了一个串联的系统。以太坊被很多人称为世界计算机，一个普通人的计算任务凭什么要让全球的矿工去计算，这个过程耗费巨大能量，而且成本很高，但并没有带来什么实质性的好处，反而耽误了整体的效率。以太坊转为 PoS 之后，更是让整个网络的矿工（节点）失去了进化动力。而中本聪设计的 UTXO 模型，天然适合高并发、高性能，我相信会有更多的 Web3 用户看到 UTXO 模型的潜力。
2、是 UTXO 模型导致比特币不具备智能合约能力吗？如果要在 UTXO 模型的基础上实现智能合约能力，一般通过什么机制来实现？

Cipher：肯定有很多种方法可以在 UTXO 模型的基础上实现智能合约能力，我介绍一下我最熟悉的 CKB 是如何实现的。
CKB 引入了 lock script，它和比特币的 lock script 是一致的，当这个 UTXO 被花费的时候，lock script 会自动执行，它会根据 witness 里面的数据来作为输入，以及当前的交易也会作为输入来执行。它跟比特币的 lock script 的区别是，它支持一个完整的图灵完备的虚拟机，而不是比特币那种非常有限的脚本环境，所以在解锁的这个阶段它是图灵完备的。
同时，CKB 又引入了 type script 字段，这个字段不论是输入还是输出它都会执行，它更多的是作为这个资产的类别，或者说同一个 type 就代表同一种资产这种逻辑来执行的。比如说，fungible token 交易前后总量保持不变，non-fungible token 交易前后这个数量保持不变、内容保持不变，或者用来判断谁有权利如何去增发一种新的资产，等等。它本身也是一个图灵完备的 VM。
CKB 的虚拟机基于 RISC-V 硬件指令集，任何的调整都涉及到重新的流片，所以 RISC-V 指令集的设计非常的精简、高效和周全。
总结一下，CKB 采用了 RISC-V 的虚拟机，它是图灵完备的，而且它还有 lock script 和 type script 两个地方来存放智能合约的脚本，并且还有一个叫 data 的字段来存放智能合约的状态，所以它是一个完整的合约执行环境。
Tim Xie：在我们 Shell Finance 的整个产品构建过程当中，因为我们要做 lending protocol，要做清算，所以需要一些高级合约的功能，最后我们选择了 DLC（Discreet Log Contracts，谨慎日志合约）。DLC 和闪电网络都属于同等级别的扩容技术，都是 offchain，不同点在于闪电网络主要做 payment，而 DLC 主要用来做 oracle。我们其实不是图灵完备的，限制依然很多，但即便是在限制很多的情况下，通过 DLC 我们就已经能够做 lending 了。
比特币其实有很多 OP Code，如果能启用或者解锁比如之前 DotSwap 的 Lin 提到的 OP_CAT，或是其他一些操作码，那我们其实也可以继续沿着闪电网络和 DLC 这样的路线来去创造出更多的可能性，智能合约肯定是能做的。核心点就在于有没有需求，有没有用户，有没有市场，有没有更多的人去投入时间和投入精力去构思它、去使用它、去满足用户的需求。只要有人使用，有市场，那新的想法、新的概念自然会出来。
我现在敢肯定的是比特币生态的形态一定会跟 EVM 那边完全不一样。也许在业务层面，用户的感受可能差不多，同样都是做 swap 和 lending，同样都有 oracle，但背后的体系以及最后能够使用的工具其实有巨大的差异性。如果是在比特币主网，这个差异会更大，所以我其实比较期待有较好 UTXO 结构的 L2，因为它可以更大地释放比特币生态的潜力。
Lin：我觉得把一个东西设计成图灵完备其实不是很难的事情，反而图灵不完备是很难的，把脚本设计成非图灵完备其实是个非常高深的技术活。
比特币原先的脚本是可以做到图灵完备的，只是现在的比特币很多能力被封印了，比如我之前提到的 OP_CAT，它是一个很重要的能力，但这个能力却被操作符禁用了，而不是说比特币一开始设计的时候没有这些操作符。比特币在一开始的时候涉及了非常多的操作符，但是因为所谓的安全性，或者是所谓的这种安全性的隐患，或者是没有搞清楚到底是什么、怎么用等等，就把某些操作符给禁用了。更有甚者，很多本来是可以用来做智能合约的这种功能，被所谓的标准交易做了一个过滤。我们都说比特币是一个去中心化的系统，但在这个去中心化的系统中，竟然还有一个叫标准交易的东西，它是由某些组织来决定的。标准交易在矿工领域是不存在的，因为矿工可以去打包任何的合法交易，它是基于用户端的一个 policy 问题。
所以总的来说，我觉得原始比特币的这种能力本身是很强大的，但是现在比特币受到了劫持，大家如果有兴趣的话，可以看一下 Roger Ver 的书《Hijacking Bitcoin: The Hidden History of BTC》。因为比特币原始的能力受到了封印，所以我们就被迫地在各种地方去找出路，这是我们目前所面临的一个现状，但是比特币的前途和未来肯定是比较好的。
我一直在说现在的很多所谓的比特币 L2 其实是寄生虫协议，它们并不是把自己的价值贡献到比特币上，也没有办法让矿工有更高的收入，但实际上也确实是没有办法，因为比特币的限制非常多。我讲个类比，HTTP 协议其实是构建在 TCP/IP 协议上的 L2，而我们的 HTML 协议又是构建在 HTTP 协议之上的。这里我觉得才是一层一层的概念，而不是说交易数据完全的从 TCP/IP 里面分离出来，从上一层协议里面分离出来，去另外一个地方跑，然后回头跟别人说我这个是二层协议。真正的二层协议其实是一层一层堆叠的，所以，我们去构建的那些 L2，它也应该是在上一层里面被接受为合法的交易。这就是为什么我们现在正在一层的 swap 上面做探索的一个很重要的原因。我们认为大部分情况下我们其实是要 settle 到一层，我们要在一层上面有很多的验证和共识的承载，而不是说我去做一个所谓的资产桥，然后把大家的资产搬到另外一个地方，这可能不是一个特别好的事情。
NIGO：UTXO 模型能否支持复杂的智能合约功能？当然是可以的。它就是将合约的逻辑和数据存储在 UTXO 中，然后将合约的调用和参数作为 input 来尝试解锁合约，通过 BVM（Blockchain Virtual Machine）执行合约的逻辑，最终通过解锁函数返回 ture or false 来达到控制合约状态的目的。这种模式可能对于以太坊智能合约的开发者来说有些陌生，但实际上，如果你结合函数式编程思想，再配合一些概念的转换，UTXO 智能合约可以实现非常复杂的逻辑。
UTXO 模型由于不存在全局状态，因此它需要将合约的状态和逻辑存储在 UTXO 中，然后通过 UTXO 交易调用链的传递来进行状态的传递和转换，所以每一次的 UTXO 交易都会消耗之前的 UTXO，并生成新的 UTXO，通过这种方式可以实现合约的链式状态转移。所以，能否解锁 UTXO，也就对应着合约的执行结果，它是否允许状态进行转移。如果合约判断不允许修改状态，比如不允许转账、不允许修改数据等，它则会返回 false，那 UTXO 不会被解锁，合约执行失败。
我们把合约看作对数据状态进行转移操作的状态机，那么这里就可以看出来 UTXO 合约和账户型合约的区别。账户合约的 EVM 是要维护全局状态，一个交易可能导致 EVM 进行多次的状态转移，频繁的修改状态数据直到合约执行或者 gas 消耗完。而 UTXO 合约的交易，它是一个 input 合约，调用只会触发一次状态转移，并且无论合约内部的逻辑多复杂，状态转移多少次，BVM 只会将最终的状态转移结果记录在链上。所以 UTXO 合约没有全局状态，只有一个个等待被执行的函数。
UTXO 是多输入多输出，以太坊想做的，包括 Monad 也想做的并行 EVM， 其实完全可以通过 UTXO 来实现，需要转移状态就要先找到这个状态所在的函数，通过函数调用来修改状态，并且生成新的函数，这样的模式使得 UTXO 合约的状态转移更加清晰了。

UTXO 合约并不依赖外部状态，因此，一次合约调用，无论调用多少次，它的结果必然是确定的，所以这也就跟合约的分析和调试以及单元测试带来了巨大的便利。而 EVM 合约要依赖全局状态，所以合约的执行结果很可能会受到外部环境的影响，导致合约的执行结果不确定，比如说余额够是一个结果，不够又是另一个结果。所以这也是 EVM 合约的安全性和可预测性的一个重要问题。

当然，每次将状态传递下去也不是没有代价的，在一些需要溯源的场景中，状态可能会随着 UTXO 传递链条的增大而增大，因为溯源是需要校验的，数据越来越多，所以状态本身会无限膨胀。我们 TBC 通过其他技术和哈希、数据抽取等密码学的手段，将状态膨胀的一大的问题给解决了。所以 TBC 的智能合约区别于其他 UTXO 链的一个重要特点是， UTXO 模型是 TBC 进行无限扩容的一个基础，使 UTXO 模型进行标准的转账交易是非常简单的。
综上，TBC 在充分考虑了 UTXO 模型的优势和缺点，在吸取以太坊和其他 UTXO 公链精华的基础上，引入了一个 BVM 的概念和其他技术来实现真正的一层 UTXO 的智能合约，然后配合更加友好的一些智能合约开发工具，降低了编写和部署 BVM 智能合约的门槛。

（未完待续）

本文转载自 TechFlow，作者 Echo、BiHelix（Satoshi Labs），指导洪蜀宁，原文链接：https://www.techflowpost.com/article/detail_15632.html 
“UTXO 区块链奠定了当今区块链行业的基础和无可争议的根基。UTXO 技术反映了中本聪对金融终极自由的核心愿景。" UTXO 模型保证了金融活动核心的安全，数据隐私和可扩展性，是对比以太坊账户模型一个更安全的替代品。
区块链原理：UTXO 模型的基础

区块链是一种数字化、去中心化、分布式的账本。区块链利用 P2P（点对点）网络，网络上的参与者称为节点。分类账存储有关交易的数据。区块链，最重要的特征是区块通过加密方式链接在一起。

区块链：以密码方式链接在一起
除了第一个块（称为创世块）之外，区块链中的每个块都包含一个称为 “前一个哈希” 的字段。它是区块链中前一个块的哈希值，也是区块链安全的基础。

决定区块哈希值的因素。如果这四个因素中的任何一个发生变化，即使是 1  位，哈希也会完全改变，这是由于雪崩效应。交易存储在块内，也是改变块哈希的四个因素之一。这意味着如果矿工选择不同的交易并保持其他 4 个因素相同，则哈希值将会不同。
1. 时间戳
2. 区块号：链中当前区块的序号。
3. 数据：存储在区块上的交易。
4. 随机数
如果攻击者试图更改块的数据，则该块的哈希值将发生变化。如前所述，下一个块将保存当前块的哈希值，如果哈希值发生变化，那么链将被破坏。或者，攻击者必须从该点开始再次挖掘所有区块。这是 51% 攻击中的一种可能性。

什么是 “区块”？

区块链中的块存储交易。就比特币而言，区块每 10 分钟就会添加到区块链中，根据目标哈希的复杂性，挖掘新区块的时间可能会有所不同。
当矿工成功开采该区块时，它就会被添加到区块链中。当区块被添加到链上时，区块内所有交易的状态都会从未确认变为已确认。就比特币而言，一个块内可以存储的交易数量并不固定，但块的平均大小是 1 MB。空块是有效的，这意味着空块可以被挖掘并添加到链中。

区块链交易结构
剥离单个交易会发现交易中具有不同语义的几种不同结构。以下是交易中存在的不同结构：

交易版本号：它是向网络指定交易类型的版本号。通过交易编号，节点可以确定用于验证该特定交易的规则集。
输出：交易输出由密码锁和时间组成。输入：交易输入由指针和解锁密钥组成。指针指向之前的交易输出。解锁密钥用于解锁输入指向的先前输出。每次通过输入解锁输出时，都会在区块链数据库中将其标记为已用。锁定时间：指定交易是否可以立即或在指定时间后包含在区块链中。

UTXO 是所有尚未被输入解锁的输出。
一旦输出被解锁，它们就会从循环供应中移除。新的输出取代了它们。因此，解锁输出的总和将始终等于新创建的输出值的总和。

什么是 UTXO 模型？
UTXO 不是加密货币面额，例如比特币（BTC）的 satoshi 或以太坊（ETH） 的 gwei；然而，UTXO 可以用这些面额来衡量。UTXO 代表未花费的交易输出。在比特币中，交易一直存在，直到它被执行，直到另一笔交易从该 UTXO 完成为止。当交易完成时，未使用的输出将作为输入存回数据库，稍后可用于另一笔交易。

当用户通过钱包发起交易时，包含交易信息的 UTXO 会被定位、解锁，并且新所有者的信息会与转移给他们的 UTXO 相关联。并且该用户可以通过相同的过程在交易中使用它们。随着交易的继续，数据库中将填充所有权变更的记录。输出是用户发送给某人但未花费的加密货币的一部分。它们作为加密货币分数的输入记录到数据库中。
当用户通过钱包发起交易时，包含交易信息的 UTXO 会被定位、解锁，并且新所有者的信息会与转移给他们的 UTXO 相关联。并且该用户可以通过相同的过程在交易中使用它们。随着交易的继续，数据库中将填充所有权变更的记录。输出是用户发送给某人但未花费的加密货币的一部分。它们作为加密货币分数的输入记录到数据库中。

UTXO 是如何创建的？
UTXO 是通过消耗现有 UTXO 创建的。每一笔比特币交易都由输入和输出组成。输入消耗现有的 UTXO，而输出创建新的 UTXO。当决定花费比特币时，我们只能看到已扣除的金额以及钱包中剩余的金额。对于用户来说，这类似于用 1 美元的钞票购买 0.50 美元的商品 — 得到零钱，将其放入口袋中。

UTXO 模型的优势
UTXO 模型不包含协议级别的钱包。它基于分组在块中的单个交易。UTXO 模型是许多加密货币（尤其是比特币）常见的设计。
使用 UTXO 模型的加密货币不使用账户或余额。相反，UTXO 在用户之间转移，就像实物现金一样。
UTXO 模型中的每笔交易都可以将系统转变到一个新的状态，但是每笔交易都转变到一个新的状态是不可行的。网络参与者必须与当前状态保持同步。

区块链中存在的总 UTXO 代表一个集合，并且由每个比特币节点不断维护。
每个事务都会消耗该集合中的元素并创建添加到该集合中的新元素。每次区块链中接受新块时，UTXO 集都会更新，网络中的每个比特币节点都将在其本地存储中设置 UTXO 的精确副本。完整的 UTXO 集可以相加来计算给定时间点的加密货币的总供应量，在有效的区块链交易的情况下，只有未花费的输出才能用于为进一步的交易提供资金。为了防止双重支出和欺诈，只有未花费的输出才能用于进一步交易的条件是必要的。

UTXO 模型与以太坊账户模型的区别

未使用的交易输出是比特币和其他加密货币背后的分布式数据库技术的一部分。比特币使用 UTXO，但它不是 UTXO。此外，以太坊使用基于账户的方法和账户余额，因此以太坊虚拟机中没有 UTXO。

UTXO 的技术重要性
与语言无关的智能合约：基于 UTXO 的智能合约独立于语言，允许 UTXO 开发独特的共识机制。支持去中心化交易所和原子交换：UTXO 模型可以支持原子交换，从而无需第三方参与即可实现点对点加密交易。UTXO 的原子交换功能为用户钱包之间的直接加密货币交易提供了更好的便利。可扩展性优势：设施或并行事务处理减少了区块链网络上的计算负载。隐私和安全：每笔 UTXO 交易都使用新地址，因此无法跟踪交易。防止双重支出：UTXO 只能使用一次，这是区块链技术运行的基础，可保证货币不会被多次使用。更灵活：它比法定货币提供更大的灵活性。简单并行化：它允许智能合约中交易的更简单并行化。
UTXO 模型用于许多加密货币，因为它允许用户跟踪该加密货币所有部分的所有权。由于加密货币在创建时考虑了匿名性，因此 UTXO 与整个网络可见的公共地址相关联。
除非用户公布其地址，否则无法通过其所有权来识别用户，但该模型允许通过地址实现透明度。
UTXO 用例：RGB 的链下转移方案
RGB 协议的核心理念是，仅在必要时调用比特币区块链，也就是利用工作量证明和网络的去中心化来实现重复花费保护和抗审查性。所有代币转移的验证工作从全局共识层中移除，放在链下，仅由接收支付的一方客户端验证。

工作原理
在 RGB 的某个合约中，创世代币都归属于一个比特币的 UTXO（无论是已经存在的，还是临时创建的），而为了转移代币，你需要花费此 UTXO。在花费这个 UTXO 的时候，比特币交易必须额外添加一个输出，该输出包含对一条消息的承诺，这条消息的内容就是 RGB 的支付信息，它定义了输入，这些代币将被发送到哪个 UTXO，资产的 id，数量，花费的交易以及它需要附加的数据。
注：比特币一层资产发行协议 RGB++ 也利用了 UTXO 作为一次性密封，且已于 4 月初上线主网，点此了解 RGB++ 的更多知识。

总结
UTXO 的本质其实是一种流水记账：通过 UTXO 模型检验交易资金存不存在，然后追溯这笔交易的源头，确定无误后通过共识机制进行全网广播，记录到链上。整个过程中，UTXO 会把牵扯到的账户资金、交易地址，转账资金、资金来源等信息全部记下，从而能够追踪到每一笔交易的最初来源，也正是基于这个特点，UTXO 可以和共识机制一起解决双花问题。
总的来说，UTXO 不仅可以协助共识机制，解决区块链双花问题，赋予了区块链可追溯的特点，区块链也能以此为基础，保证每笔交易的真实与可靠。

#UTXO 的英文是 Unspent Transaction Output ，翻译过来叫 “未消费的交易输出”。应该这么说，比特币的核心概念交易，交易的核心知识点就是 UTXO ，所以这篇中咱们好好聊聊这个 UTXO。
交易的组成要素
比特币中是没有账户这个概念的，所谓一个地址的余额，其实就是统计这个地址相关的所有交易，然后运算出来的。所以我们把显微镜调调焦距，先看看一个交易中都包含哪些要素。

第一个要素是输入，也就是 Input。首先，并不是所有的交易都有这一项。比如每个区块里面都有一个矿工自治的特殊交易，也就是所谓的 coinbase 交易，它就是一个没有 Input 的交易。这个交易中直接把一定数量的比特币转出给制作这个区块的矿工。除了这个特例之外，其他的交易都是有输入的。比如小明想给小刚转账1个比特币，这个交易的 Input 应该是啥呢？是和小明的地址相关的一些交易，更准确的说，就是这些交易中包含的属于小明地址的未消费的交易输出，也就是 UTXO 。
于是我们就很自然的进入了第二个要素，也就是交易中应该包含输出。“输出”是个术语，英文叫 Output。在小明给小刚转账一个比特币的交易中，交易的 Output 就是指向小张的地址的这一个比特币。这样，UTXO 中的后三个字母 TXO ，其中 TX 代表交易，O 代表 Output，我们就理解了。
最后一个 U 指的是 Unspent，也就是未消费。小张如果从来没有用这个 Output 做过其他交易的输入，那么这个 Output 就是没有被消费过的，就是 UTXO。
最后一个要素就是手续费，一个非 coinbase 交易中输入要等于输出加上手续费，手续费是要转账给矿工的。讨论中为了简便，我们忽略手续费这一项。
理解的比特币交易的基本组成其实也就理解了 UTXO。到任何一个比特币浏览器中点开一个具体的交易，详情中可以看到咱们刚刚说的这几个要素。
凑输入和找零
UTXO 有个特点，就是跟硬币一样，不能掰开用，那么交易过程中如何凑够输入金额，又如何找零的呢？
小明给小刚转账 1 比特币。整个过程是这样的，小明要收集足够的输入，比如小明的地址对应的以往交易中，找到了一个面值为 0.9 的 UTXO，不够 1 比特币，好在交易中是允许有多个输入的，所以小明又找到了一个面值 0.2 的 UTXO，这样在这次转账的交易中，就会有两个输入。同时输出也会有两个，一个是指向小刚地址，面值是 1 比特币。另一个指向小明的地址，面值是 0.1 比特币，这个输出就是找零了。
梳理一下，整个流程是这样的：小明首先要凑够足够面额的 Input，这里他找到了两个 Input，而这两个 Input 本身都是以往交易的 Output。这两个 Output 在未消费之前，就是 UTXO，但是当前交易一旦生效，它们两个就会被消耗掉，而本交易中又会生成两个新的 UTXO，一个指向小明，一个指向小刚。相当于小明和小刚各种领到手一个硬币，未来可以在其他交易中去消费。而小明和小刚各自地址的余额，其实就是各自对应的所有 UTXO 的总和。
这样，交易中如何去凑够输入，如何生成输出，并进行找零，我们就清楚了。

为何使用 UTXO 模型？
到这里我们就有一个疑问了，比特币不就是个大账本吗？为何不采用账户模型，而要采用 UTXO 模型呢？
账户模型是传统银行或者类似于支付宝这种服务的基本模型，这个模型下，我有一个自己对应的账户，上面记录我有 13 块钱，那么 13 这个数字是明明白白记录到系统中的。账户模型的确是非常简单，也非常灵活，以太坊以及一些其他区块链项目中采用的就是账户模型。
再看看比特币，小明有 13 个币，其实区块链上是根本没有 13 这个数字的，因为区块链上只有交易。但是我们打开比特币的区块链浏览器，是可以看到一个地址对应的余额的，这是区块链浏览器自己运算出来的，不是区块链上本来就有的。
但是很多高手会说 UTXO 是一个非常棒的模型，主要是因为 UTXO 非常适合并行运算，这个特点在分布式的计算机网络中显得非常的巧妙。具体细节不是本文要关心的，推荐阅读《UTXO 和 Account 模型对比》，里面有更详细的论述。

总结
UTXO 咱们就聊到这里，来总结几句。
UTXO 是理解比特币交易的枢纽性概念，想要理解比特币底层原理的同学，这是一个绕不过去的坑。每个交易中，可以包含多个输入，并且通常包含两个输出，输出总额加上手续费正好等于输入总额。每个输出都跟硬币一样，有自己的一个面值，而且属于某个特定地址。还没有被当做其他交易的输入使用的输出，就是 “未消费交易输出”，就是 UTXO。
UTXO 模型中没有账户的概念，所以对比账户模型显得稍微绕一些，但是它本身其实也是有巨大优点的，例如非常有利于在分布式系统中进行并行计算处理。$CKB $BTC

上周，CKB 社区成员 Retric 提出了 Nostr 绑定协议（Nostr Binding Protocol）。
Nostr 绑定协议用在 Nostr Event 和 CKB Cell 之间创建一对一的映射关系。普通用户可以基于该协议在 Nostr 社交网络中创建和分发原生资产， 通过 RGB++，这些 Nostr 上的资产也可以由比特币地址进行控制。客户端开发者则能够在其上构建产品，不同于 ETH dApp 分成两个系统（一个是链下服务器，另一个是链上智能合约），Nostr 绑定协议为 dApp 带来新的开发范式，它使用一个具有不同数据级别的一致系统来构建 dApp。据悉，Nostr 绑定协议未来可以无缝集成到 CKB 闪电网络，解决社交网络中原生支付问题。

Nostr 是一个基于公私钥的、极简的信息传输协议，致力于创建一个抗审查的全球社交网络。Nostr 使用 Relay（中继器）来存储社交数据（比如帖子）并将其传输给用户，用户运行的软件称为 Client（客户端）。
今年 3 月 9 日，在由 Nervos Foundation 和 ABCDE 共同举办的首届 Bitcoin Singapore 大会上，Retric 做了一场 “Nostr 生态发展现状及问题” 的主题分享👇
以下是根据 Retric 的分享整理的内容，可以帮助大家更好地了解  Nostr 协议：
这个 Nostr 协议应该是今天这个会议里面最简单的一个东西。相比其他人讲的一些技术或者一些协议，它是最容易理解的，因为它本身也非常简单。Nostr 一开始想要做的其实是一个 “推特”，但这个推特不是由伊隆·马斯克控制的，而是一个更去中心化的推特，它不会去做一些坏事，不会去封锁别人，有一些言论自由。它想要做这个事是比较现实的一个出发点，就是想要做一个这样的软件，为此提出了一个社交网络上的去中心化的协议，叫 Nostr。然后发展到现在，大家开始意识到这些东西其实不只是可以去做一个推特，更像更好的一个互联网结构，我们可以在上面做各种各样的应用。
Nostr 这个协议我先简单介绍一下，它其实可以用一句话就把这个协议讲完：这是一个数据，通过一个私钥来签名，这个数据在不同的 Relay 或者叫中继器上去进行传播，然后发给客户端。本质上就是我签一个固定格式的数据，签完之后发到一些中继器上，然后我再让其他用户通过客户端从这些中继器上把这个数据拉下来进行读取。

Nostr 的核心东西是一个 Jason 结构，会有不同的字段，每个字段代表一个意思。比如说 pubkey 就是我签名发送数据是哪一个公钥去做签名的，比如它有 content 这一栏，这个代表说我签这条数据它的内容到底是什么，它可以是任意的一个字符串，可以是我发的一条推特，也可以是一个数字或者说一个加密的东西，协议上是不做限制的。这边也会有个签名，就是说我对我发的这个数据做了一个保证，保证这个数据确实是从我这边发出去的。
所以 Nostr 的核心就是这么简单，它其实只是代表说我在本地通过某一把私钥去对某一段我自己写的一个数据做了一个签名。这个数据发到网上之后，Nostr 网络结构也很简单，就两个结构，一个叫 Relay，一个叫 Client。

Relay 就是一台服务器，是每个人都可以架设的一台服务器。这个 Relay 的作用是它一直在网上跑，去监听有哪些人给我发了我刚才说的这个数据，然后把它接收下来，把它存下来，如果有客户端向我要某一些数据的时候，我再给他。
第二部分是这个数据怎么去传播，即传播的一个规范，这里面其实会有大量的细节。比如说我把这个数据传给 Relay，Relay 跟 Relay 之间他们互通吗？或者说我传给 Relay 之后，Relay 是不是会帮我把这些数据完整地保存下来，然后任何时候找它要，它都会给我？其实有这种细节问题。Nostr的答案是 "我不管，你们自己去想"，不管其实是有点奇怪的一个反应，但是有时候我觉得不管是一种比较高明的策略。有时候好像不管在现实世界还是在网上，有时候因为管太多反而去伤害一些事情，所以我觉得它不管其实非常有意思。
比如说我举个简单例子，我们在用比如说传统的中心化社交网络的时候，那个中心化服务器会默认把你所有数据都存下来。然后你找我要的时候，我任何时候都可以给你，但因为 Nostr 是不管的，所以这里面会出现什么情况？有些 Relay 的运营者想要做大做强，他想要把所有消息全部保存下来，这是一种。还有一种我是一个爱好者，我只想搞一个很小的节点，我只对我喜欢的那些用户去接受他们的数据。还有一些是我愿意接受你数据，但是我接收后可能 30 分钟后我就不想要了，我要把你删掉，因为我服务器的那个磁盘可能是有限的，我不愿意保存那么久。
所以它其实会演化出很多不同的角色，这些不同角色可能就会有不同分工。比如说有些真的想要去把它当做一个生意来运行的话，那我就会去做一个专业的服务节点，尽可能给大家提供比较稳定比较长时间的服务。也有一些爱好者，他也可以跑那种局域网一样的东西，所以它会演化出不同的这种分工。
普遍的一个现象是，大部分 Relay 节点它愿意接收你的一些消息，但是它不能保证会长时间给保存下来。这种结构其实它好像更适合我们真实人类社会中的一些社交模式。真实的社交模式，比如说我今天在这里跟大家聊天，我一说话，你们能听到，你们也知道，然后离开会场。过两天之后，有些人记忆不太好就已经不记得我在说什么了，但是有些人在这会场买个录音机，把你说的话每个字都记下来，这个就代表说你这个消息是不是会一直保留下来。
这其实就很像我们现实中在发生的一个事情，这个事情能发生就是因为 Nostr 对很多细节或者很多其他事情并不去做规定，并不管，包括 Relay 跟 Relay 之间到底需不需要通信，它们需不需要同步彼此拥有的消息，它是不规定需要，但它并没有说你不能。所以也有很多 Relay 会把自己假扮成一个 Client，它也会去找其它 Relay 要它的数据，把所有数据同步下来。但是它不去做强制性的要求，说你必须通信，它的一个理由是如果我做了这个要求，你必须要通信，那就会变成每个 Relay 都必须保存全网每个用户的数据，那样的话对运营 Relay 是一个非常大的考验。可能只有那些专业服务商才能运营，个人爱好者可能就不会去跑。所以这是它做这个简单协议的背后的一些考量。
总结一下，我觉得 Nostr 协议非常简单。另一个，它有趣的地方其实是在现在这么一个节点，就我们有了比特币，有了 blockchain 之后，想要有的一个共识是，就好比我们大家都坐下来说，我们今天用一种统一的格式、统一的协议去做一些社交网络或者做互联网的一些产品，它其实出现在很有意思的一个节点。但现在这个节点我觉得有这么一个想努力的方向，就是统一用一种很简单的数据结构，很简单的交换协议去做一些微信、推特等在做的事情。所以我觉得它可能协议上你看一眼会觉得很简单，好像没什么意思。但如果你去想它背后出现的时间，出现的这个意义会觉得有意思一些。
另外一点是因为它这套结构，它其实大量的一些验证是发生在这个客户端的。这里面其实就一件事的验证，你发布的数据是不是真的由你声明了那个公私钥对发出来的，只做这个验证。为什么做这个验证，因为比如说我如果发了一条推特，说了些不该说的事情，这条会发给 Relay。Relay 再负责发给别人，那 Relay 如果不做验证，Relay 可以说我伪造了你说的一句奇葩的话发给其他用户。因为我在发数据的时候是有签名的，所以拿到那个数据的客户端它可以做一次验证，说确实他签的这个签名跟他说的这个话是完全匹配的，这样 Relay 就骗不了别人。
所以它的一个验证是做签名的这个校验，这个签名的校验实际上是把过去我们中心化的互联网比如说微信，微信上的服务器它是自己控制的，它可以在服务器上写任何东西，你没有办法去确定说它有没有骗你，因为所有的数据所有的权利都在服务器上。但只要有最简单的一个验证，我们实际上可以把权利从服务器那边剥离出来，交给拥有账号的这个用户。只要你有一个公私钥，你就可以让你的朋友去做验证，确定说不是其他人要冒充我或者说一些什么其他不对的话。
那 Nostr 的发展到底怎么样呢？这是我 3 月份翻到的一些数据。因为这是一个分布式的网络，所以它的数据其实是不太好统计的，这是我从 nostr.band 网站获取的数据，Nostr 总用户可能是 37 万左右，日活可能就 12,000。总共的 Relay，出现过的 Relay，有多少人去跑过这个节点，可能有 2000+。但实际上一直在线的这些节点有多少，可能在 200 个以下。大概是这么一个情况，所以用户还是比较少。
作为对比，你看它跟 BlueSky 协议的一个对比。Bluesky 应该是去年底就说他们达到 200 万用户了，右边那个数据是有人统计的从推特出走的那些用户他们去了哪里，你也可以看到，Mastodon 排第一个，Mastodon 是一个比较老牌的一个协议了，然后也有人去了 ost news，也有人去了 BlueSky，Nostr 其实是属于第五梯队，就比较小的那一部分。

这是它大概的一个发展的情况，当然Nostr背后有很多其实这种数据看不到的一些东西，比如说对协议提交了一些提案，开发者去给它提交了一些 PR。这些开发的活动或者一些讨论，这些数据可能没办法统计到，但如果你点进去这些链接的话，其实可以看到发生的这些事情还是很多的，有大量的人在想要为这个协议做贡献。这个是大家用 Nostr 去做的一些东西，就不只是说我真的做一个推特，也有很多做一些音乐类的应用，做这个 YouTube 类型的应用，也有做博客类的应用。
所以我来总结的话，现在我们觉得大部分的用户其实还是 developer 或者 maker。他们对协议本身感兴趣，想在上面开发东西，或者我是一个想要做一些东西的人，我会在你协议上，可能普通的那种 users 会少一些。
为什么 Nostr 这么简单，愿景看起来不错，但发展不是非常尽人意，我觉得也是因为有遇到三个问题，我其实在写这个 PPT 的时候发现其实有非常多无数的细节的小问题，比如说客户端，一些产品体验上的一些东西。但是这种东西其实是很难去把它讲清楚，所以我就举了三点我觉得比较重要。
第一个大问题是你怎么在 Nostr 这个网络里面去找到某个用户发的内容在哪儿，因为我们前面说了整个 Nostr 协议的运转是我在本地签东西，然后可以发给无数的 Relay 们。其他用户可以从这些 Relay 里面抓取我发的数据来阅读，这么一种模式。但是这个模式有个问题，就是我这个数据发给 Relay 之后，我的朋友想要读这条消息的时候，他怎么知道我这个消息是放在哪些 Relay 上，他得知道哪些 Relay 有我这个数据，他才去读。所以现在一个很大的用户体验问题是，很多人在用 Nostr 的时候会问他朋友：“嘿，你用的是哪些 Relay，我要跟你设置一样的 Relay，这样我们才能共同去交换这个数据。”这是个很笨的方法。
当然到现在也有很多开发者提出了一些详解的方案，比如说有一个 NIP-65 的提案，它大概意思是我把我的数据会放到哪几个 Relay 上这一条信息我也放在 Relay 上。然后我把这条信息尽可能传播给所有的 Relay，这样的话我的朋友首先会去找 Relay 问一个问题，我这个朋友他平常把他的消息发在哪些地方。拿到这个信息之后，他再去找我常发布的那几个 Relay，找他们要这些数据，这是一种方法。
它分得比较细的两种模式，一种叫 Inbox，一种叫 Outbox。比如说像 Inbox，它让用户定义我会从哪几个 Relay 里面去读关于我的一些消息。如果你想要在 Twitter 上@我或者想做其他事，你可以往这个 Inbox Relay 里面去发这个信息。另一个是Outbox Relay，指明说我会往 A、B、C、D 的好几个 Relay 里面去发我的一些消息，大概意思就是我把我常发布的一些 Relay 信息，首先也发在 Relay 上。
但是这有一个技术难题诞生了，就是我怎么知道这个消息是在哪儿。所以这其实也会有这个问题，还有一些解决方案是说我通过一些算法，我尽可能在全网去下载尽可能多的一些信息。然后从别的人发的一些信息里面提到的一些 Relay 隐藏的证据，去尝试把一个人他发布的数据出现在哪几个 Relay 上的概率做一个计算。通过这种概率的计算去尽可能找一些Relay要数据，然后去满足别人想读你的数据的时候能找到你的数据。还有一些也是让用户去定义自己会使用的一些 Relay，做一些分组，也是让其他用户通过这些分组去找到你，这是现有的一些改善的方案。
第二个问题也是比较严重的，叫 Content Governance。不管是内容产品或者说社交网络上有很大的一部分精力是需要放到你怎么去维护这个社交网络上的内容。比如说你肯定不需要刷推特的时候刷到一个别人砍头的视频，对吧，这是非常糟糕的体验。就这种那些公司背后会做大量的运营，它需要有很多人去过滤这些内容，或者去用算法去做一些内容匹配，这部分当中，市场上是比较空白的。这个有好几个方面的原因，有一个原因是大家在这个平台上会非常排斥算法。因为觉得好像不管是 TikTok 还是 Youtube 都是算法来控制我们，但实际上我们确实是需要算法，只是说我们需要的是我可以切换算法。
我不希望说我只能接受用 Youtube 或者 TikTok 给我的强制性的他们要推广告的算法，我希望是我有很多算法可以随时做切换。我如果不喜欢这个算法，有选项我可以退出，这个观点其设计也在慢慢接受。只是说现在这块，不管是包括人工的那种或对内容做的一些运营，还是说在算法技术上做的一些事情，这些都还比较欠缺。所以这部分主要问题是我们这网络是所有人共同组成的，它需要有个机制去决定哪些内容是好的，哪些内容是不好的，哪些内容是你会感兴趣的，哪些内容可能是你不感兴趣的，这其实是内容治理的一个问题。
下面这边是我列的一些现有的改善方案，比如说第一个 labeling data。在这个 Nostr 上有一种专门的数据，是可以让用户自己去标记某一些数据它属于什么类型，或者说它的属性有什么。就通过这种 labeling 去给一个数据做一些标注，但是这个应用并不广泛，因为很简单，没有人愿意去干这个事情。没有人愿意去充当你的这个 social member 去帮你做一些这种苦力活，很早期的互联网社会有这种建设精神。现在其实大家更多可能作为消费者去使用，当然也有人提出说我可以做 API。我专门跑一些服务，我去搜集全网的一些公司的数据，然后我去做过滤或者做分类，去拿更可能好的一些消息发给用户。这种方案是非常好做的，但是它有个巨大问题，就是这样做着做着我们又回去了。就会变成说我不找 Nostr 这个协议要数据，而变成说我专门找一家工作得特别好的 API，找这个 API 的这个服务器要数据。那这样协议做着做着变成这个 API 后面又是另一家推特或者又是另一家微信，所以这个方案非常好。问题是大家不喜欢，你要是做这个的话所有人都会喷你。
还有一种方案叫 DVM，它想做的是通过 Nostr 协议去做一些使用协议规定好的接口去做这个数据的分类或者算法。它的大概意思是你给我一些闪电网络的聪，然后我会返还给你你想要的数据，你规定好数据格式，但这个也有一些问题。
另一个是 Noscript，它是另一个想法，是我们直接把这些过滤的算法或者一些分类需要用到的技术把这些代码直接也作为内容，直接放到 Nostr 上，让 Relay 去存储。然后客户端直接拉这些代码下来，在本地做一些本地能做的一些过滤或者做一些推荐。当然这个的话就发展得更不好，因为现在还只是有些 Idea，有些人在讨论。
第三个比较严重的问题其实是一个创业的问题，PMF。现在 Nostr 的大量产品或者开发者他们找不到 PMF，因为他需要面对大量竞争。一方面是中心化的传统的那些产品，另一方面可能是 Web3 区块链这边的。他们不发 token 也不干嘛，所以它其实缺少一些商业模式，也面临网络效应这个问题，因为越少人迁过来，那就意味着更少人会继续迁过来。所以 PMF 是一个很大的问题。
Nostr 最大的一个客户端叫 Damus，不知道大家有没有用过，它的开发者去年年底发了一条推，说 2024 年可能是 Damus 的最后一年。因为他快没钱继续再做下去，如果 2024 年还做不起来，还赚不到钱的话。所以这也是要给社交网络的公共物品找到可持续发展的一个方向的问题吧。
其实这里面所有问题，我觉得也是机会。比如说像最后 PMF 这个，我觉得如果我们能有更多跟区块链结合的一些地方，能有更走得通的一些商业模式，去跟区块链基金做一些结合，可能可以解决这种公共物品的一个融资问题。
最后，我觉得 Nostr 是一个新的开发 alternative applications 的一种方案。如果你想要做一些替代性的产品的话，可能不是只有两个极端，一个极端叫 blockchain，一个极端叫 Twitter。不是只有这种，可能有个中间地带叫 Nostr，它不是基于区块链的，但它也不是专属软件。谢谢。

以下内容转载自 Nervos Talk 论坛，作者 Ajian（比特币内容平台 BTC Study 主编）。原文链接：https://talk.nervos.org/t/ckb/7504 
摘要
理解一个系统的可编程性要求我们辨识这个系统在结构上的特征。对基于比特币脚本的应用编程的探索，有助于我们理解 CKB Cell 的基本结构及其编程范式。不仅如此，它还能将 CKB 的编程元件分解为恰当的部分，并帮助我们理解每一部分所带来的可编程性增益。

一. 引言
“可编程性（programmability）” 是人们在比较区块链系统时经常采取的一个维度。然而，关于可编程性的描述方法，却常见分歧。一种常见的表述是，“XX 区块链支持图灵完备的编程语言”，或者， “XX 区块链支持通用的编程”，意在表示这里的 “XX 区块链” 具备强大的可编程性。这些语句的暗示有一些道理：支持图灵完备编程的系统一般都比不支持的更容易编程。但是，智能合约系统的结构性特征有多个方面，这一语句只涉及其中一个方面，因此，不足以凭它获得足够深的理解：开发者从中得不到指引，普通用户也无法凭此分辨诈骗。
智能合约系统在结构上的特征包括：
状态表达（合约）的基本形式（账户 vs. 交易输出）是否允许编程任意计算（“图灵完备” 的说法关涉的就是这个方面）执行过程可创造新数据，还是只传出布尔值？（计算 vs. 验证）是否允许在合约内记录额外的状态一个合约在执行的时候是否可以访问另一个合约的状态
所以，在 “可否编程任意计算” 之外，至少还有四个方面的特征会影响一个智能合约系统的可编程性。甚至可以说，这些其它方面的特征是更为重要的，因为它们更深层地决定了什么容易实现、什么难以实现；什么是较为经济的实现，而什么是较为低效的实现。
举个例子，人们常常拿以太坊作为良好可编程性的例子，但是，以太坊的状态表达的基本形式是账户，它难以编程点对点的合约（例如，支付通道、一对一的打赌合约） —— 并非绝对不能实现，只是吃力不讨好。以太坊生态并非从未有过尝试实现 支付通道/状态通道 的项目，理论探讨也有很多，但时至今日这些项目似乎都不活跃了 —— 这显然不能归咎于开发者不努力。如今在以太坊上活跃的项目都采取了 “资金池” 的形式，而非 “点对点合约” 的形式，也不是偶然。同样地，当前人们也许对以太坊的可编程性很满意，但是，若要实现 “账户抽象（account abstract）”（也可以理解为钱包概念的泛化） ，账户模型却可以说是先天不足。
同理，探究 CKB 的可编程性，也要求我们理解 CKB 智能合约系统在这些方面的结构特征。我们已经知晓的是，CKB 允许编程任意计算、允许在合约内记录额外的状态、也允许一个合约在执行时访问另一个合约的状态。但是，其合约的形式是交易的输出（称为 “Cell”），这使得它跟以太坊产生了根本性的差异。因此，对以太坊智能合约系统以及其中的合约实例的了解，并不能帮助我们理解 CKB 是如何实现这些结构特性的，也不能帮助我们认识 CKB 的可编程性。
幸运的是，比特币上的智能合约，似乎为我们理解 CKB 的可编程性提供了最好的基础。这不仅是因为比特币的状态表达的基本形式也是交易的输出（称为 “UTXO”），更是因为，借助比特币社区提出的一个概念 “限制条款（covenants）”，我们可以理解 CKB 具备上述结构特性的原因，并将最终的效果恰当地分拆成几个部分、逐一辨识它们所带来的可编程性增益。

二. CKB v.s. BTC：多了什么？
（一）基本结构
作为比特币状态表达的基本形式，比特币的 UTXO（“未花费的交易输出”）有两个字段：
数额，以聪（Satoshi）为单位，表示该 UTXO 具备的比特币价值；脚本公钥，也称锁定脚本，表示花费这笔资金所需满足的条件，也即为解锁这笔资金设定条件的智能合约程序。
与后来出现的智能合约系统相比，比特币脚本是相当受限的：
它不允许编程任意计算；可用来验证的较为实用的计算只有几种（签名检查、哈希原像检查、时间检查）它不允许在合约内记录额外的状态；（例如，你无法用脚本来限制单次花费的 比例/额度 上限；也无法在其中暗藏一种 token）它也不允许在执行的时候访问另一个合约的状态（每个脚本都是独立的宇宙，互不依赖）。
这种脚本虽然有限，但并不缺乏编程出让人惊叹的应用的能力，而且也正好是我们探索 CKB 可编程性的基础。后文将有专门的一节来介绍比特币脚本编程的两个例子。
与之相对的，CKB 的状态单元称为 “Cell”，有四个字段：
Capacity，类似于 UTXO 的数额，表达的是该 Cell 可以占据的空间大小，以字节（Bytes）为单位；Lock Script，类似于 UTXO 的脚本公钥，定义该 Cell 的所有权；只有所提供的数据能够通过 Lock Script 时，才能 “更新” 这个 Cell（也可以说释放这个 Cell 并用这些 Capacity 来铸造新的 Cell）；Data，数据，任意数据，其体积受 Capacity 的限制；Type Script，可选的脚本，用于为 Data 的更新设定条件。
此外，Lock Script 和 Type Script 还可以编程任意计算。你可以编程出任意的签名验证算法，也可以编程出任意一种哈希算法的原像检查，等等等等。
读者很容易就能看出，Cell 相比 UTXO 在可编程性上的提升：
Cell 可以编程任意计算，而不是只能编程特定的几种计算；它的所有权验证会更加灵活；因为 Data 和 Type Script 字段，Cell 可以记录额外的状态；这就允许 Cell 承载所谓的 “UDT（用户自定义的 Token”）。
结合 Cell 本身的 “交易输出” 结构，这两点本身能带来的好处已然非常非常巨大，但是，仅从上面的描述，我们尚不知晓 Cell 是如何实现 “一个合约在运行时访问另一个合约的状态” 的。为此，我们需要借助比特币社区探讨了很长时间的一个概念：“限制条款（covenants）”。
（二）限制条款与内省
限制条款的本意是限制一笔钱能被花到哪里去。在当前的比特币（尚未部署任何限制条款提议）上，一笔资金一旦解锁，就可以花到任何地方（可以支付给任意的脚本公钥）。但限制条款的想法是，可以用某种方式，限制它只能花到某些地方去，比如，某一个 UTXO 将只能被某一笔交易花费，那么，即便有人能够为这个 UTXO 提供签名，它可以花到什么地方也已经被这笔交易决定了。这种功能看起来有点奇怪，却能产生一些有趣的应用，后文会有专门的一节介绍。重要的是，它是我们进一步理解 CKB 可编程性的关键。
Rusty Russell 正确地指出，限制条款可以理解为对交易的 “内省” 能力，即，当一个 UTXO A 被一笔交易 B 花费时，脚本运算程序可以读取交易 B 的部分（或者全部），然后检查它们是否与脚本预先要求的参数一致。例如，交易 A 的第一个输出的脚本公钥，是否与 UTXO A 的脚本公钥所要求的一致（这就是限制条款的最初含义）。
敏锐的读者会意识到，如果具备了完全的内省能力，那么一个交易的输入就可以读取同一交易的另一个输入的状态，这就实现了我们前面说的 “一个合约在运行时访问另一个合约的状态” 的能力。事实上，CKB Cell 正是这么设计的。
基于此，我们又可以将这种完全的内省能力分成四种情形：
Lock Script 读取其它（输入和输出）的 Lock ScriptLock Script 读取其它（输入和输出）的 Type Script（以及 Data）Type Script 读取其它（输入和输出）的 Lock ScriptType Script 读取其它（输入和输出）的 Type Script（以及 Data）

这就允许我们在一定的假设（Lock Script 和 Type Script 的功能分工）之下分析每一部分的内省能力在不同应用场景中的作用，也即分析每一部分为我们带来的可编程性增益。
在下面的两个章节，我们将分别了解当前（尚未限制条款提议）的比特币脚本编程，以及限制条款提议有望实现功能，从而具体地理解 CKB Cell 如何编程并做得更好。
三. 比特币脚本编程
本节将使用 “闪电通道/闪电网络” 和 “谨慎日志合约（DLC）” 作为基于比特币脚本的应用编程的案例。在展开之前，我们要先了解两个概念。
（一）OP_IF 以及 “承诺交易”
第一个概念是比特币脚本中的流程控制操作码，比如：OP_IF 、OP_ELSE。这些操作码跟计算机编程中的 IF 没有什么区别，它的作用就是根据不同的输入执行不同的的语句。在比特币脚本的语境下，这意味着我们可以设置资金的多个解锁路径；搭配时间锁特性，这意味着我们可以分配行动的优先权。
以著名的 “哈希时间锁合约（HTLC）” 为例，这种脚本翻译成大白话就是：
要么，Bob 可以揭晓某个哈希值 H 背后的原像，再给出自己的签名，即可花费这笔资金；
要么，Alice 可以在一段时间 T 过后，凭借自己的签名花费这笔资金。
这种 “要么 …… 要么 ……” 的效果，就是通过流程控制操作码实现的。
HTLC 最突出的优点是它可以将多个操作捆绑在一起、实现原子化。例如，Alice 希望跟 Bob 以 BTC 交换 CKB，那么，Bob 可以先给出一个哈希值，并在 Nervos Network 上创造一个 HTLC；然后 Alice 在比特币上创造一个使用相同哈希值的 HTLC。要么，Bob 在比特币上拿走 Alice 支付的 BTC，同时也揭晓原像，从而允许 Alice 在 Nervos Network 上取走 CKB。要么，Bob 不揭晓原像，两个合约都过期，Alice 和 Bob 都可以取回自己投入的资金。
在 Taproot 软分叉激活之后，这种多解锁路径的特性因为 MAST（默克尔抽象语法树） 的引入而得到进一步的强化：我们可以将一条解锁路径变成默克尔树上的一个叶子，每个叶子都是独立的，因此不再需要使用这样的流程控制操作码；而且，因为揭晓一条路径时无需曝光其它路径，我们可以为一个输出加入更多数量的解锁路径，而不必担心经济性问题。
第二个概念是 “承诺交易”。承诺交易的想法是，在一些情况下，一笔有效的比特币交易，即使它不得到区块链的确认，也同样是真实的，有约束力的。
例如，Alice 和 Bob 共同拥有一个 UTXO，这个 UTXO 需要他们两人的签名才能花费。这时候，Alice 构造一笔交易来花费它，将其中 60% 的价值转移给 Bob，剩下的价值转移给自己；Alice 为这笔交易提供自己的签名，然后发送给 Bob。那么，对 Bob 来说，不必将这笔交易广播到比特币网络中，也不必让这笔交易得到区块链的确认，这笔交易的支付效果也是真实的，可信的。因为 Alice 无法独自花费这个 UTXO（因此无法重复花费），也因为 Alice 所提供的签名是有效的，Bob 随时可以加上自己的签名，然后广播该交易，从而兑现这笔支付。也即，Alice 通过这笔有效的（不上链的）交易，给 Bob 提供了一个 “可信的承诺”。
承诺交易是比特币应用编程的核心概念。如前所述，比特币的合约是基于验证的、无状态的、不允许交叉访问的；但是，如果合约不携带状态，那这些状态存放在哪里、合约如何安全推进（变更状态）？承诺交易给出了直截了当的答案：合约的状态可以用交易的形式来表达，从而，合约的参与者可以自己保存状态，而不必将它们展现在区块链上；合约的状态变更问题，也可以转化成如何安全地更新承诺交易的问题；此外，如果我们担心进入一个合约会有危险（例如，进入一个要求双方都签名才能花费的合约，会面临对方不响应从而卡死的风险），那么，只需提前生成花费该合约的承诺交易并获得签名，就可以化解风险、消除对其他参与者的信任。
（二）闪电通道与闪电网络
闪电通道是一种一对一的合约，在这种合约中，双方可以无限次地相互支付，而不必让任何一次支付获得区块链的确认。如你所料，它用到了承诺交易。
在解释 “承诺交易” 的部分，我们已经介绍了一种支付通道。但是，这种仅利用 2-of-2 多签名的合约仅能实现单向支付。即，要么一直是 Alice 向 Bob 支付，要么一直是 Bob 向 Alice 支付，直至用尽自己在合约中的余额。如果是双向支付，那就意味着，在某一次状态更新之后，一方的余额可能变得比以前更少，但是，TA 却拥有对方签过名的上一笔承诺交易 —— 有什么办法阻止 TA 广播旧的这笔承诺交易、让 TA 只能广播最新一笔承诺交易呢？
闪电通道解决这个问题的办法叫做 “LN-Penalty”。现在，假设 Alice 和 Bob 在一条通道中各拥有 5 BTC；现在 Alice 要给 Bob 支付 1 BTC ，于是签名这样一笔承诺交易，并发送给 Bob：
输入 #0，10 BTC： Alie-Bob 2-of-2 多签名输出（即通道合约）
输出 #0，4 BTC： Alice 单签名
输出 #1，6 BTC： 要么 Alice-Bob 联合临时公钥 #1 单签名 要么 T1 时间锁，Bob 单签名
Bob 也签名一笔（跟上述交易恰成对应的）承诺交易，并发送给 Alice：
输入 #0，10 BTC： Alie-Bob 2-of-2 多签名输出（即通道合约）
输出 #0，6 BTC： Bob 单签名
输出 #1，4 BTC： 要么 Bob-Alice 联合临时公钥 #1 单签名 要么 T1 时间锁，Alice 单签名
这里的诀窍，就在于这个 “联合临时公钥”，它是使用己方的一个公钥和对方提供的一个公钥生成的，例如，Alice-Bob 联合临时公钥，是 Alice 使用自己的一个公钥，和 Bob 提供的一个公钥，各自乘以一个哈希值再相加，得出来的。这样一个公钥，在生成出来的时候，是谁也不知道其私钥的。但是，如果 Bob 把自己所提供的公钥的私钥告诉了 Alice，Alice 就可以计算出这个联合临时公钥的私钥。—— 这就是闪电通道可以 “撤销” 旧状态的关键。
在下一次双方要更新通道状态（发起支付）时，双方就交换上一轮中交给对方的临时公钥的私钥。如此一来，参与者就再也不敢广播自己得到的上一笔承诺交易：这笔承诺交易为己方分配价值的输出有两个路径，而临时公钥路径的私钥已被对方知道；所以一旦广播旧的承诺交易，对方就可以立即动用这个联合临时私钥，从而将这个输出中的资金全部拿走。—— 这就是 “LN-Penalty” 的含义。
具体来说，交互的顺序是：发起支付的一方先向对方请求新的临时公钥，然后构造一笔新的承诺交易并交给对方；得到了承诺交易的一方向对方曝光自己在上一轮给出的临时公钥的私钥。这样的交互顺序保证了参与者总是先得到新的承诺交易，然后才作废自己在上一轮中得到的承诺交易，因此是免信任的。
综上，闪电通道的关键设计有：
双方总是使用承诺交易来表达合约内部的状态，并以数额的变化来表示支付；承诺交易总是花费同一个输入（需要双方同时提供签名的输入），因此所有承诺交易都是相互竞争的，最终只有一笔能够得到区块链的确认；两个参与者签名的并不是同一笔承诺交易（虽然它们是成对的）；而他们所签名的总是对自己更有利的交易，换句话说，参与者收到的承诺交易，总是对自己不利的；这种不利体现在，为自己分配价值的输出带有两个解锁路径：一条路径可以凭自己的签名解锁，却需要等待一段时间；而另一条路径则用到了对方的公钥，仅当自己的一个临时私钥不暴露，才受到保护；在每一次支付中，双方都以新的一笔承诺交易来交换对方在上一轮使用的临时私钥，从而，交出了临时私钥的一方就不再敢广播旧的一笔承诺交易，因此，就 “撤销” 了上一笔承诺交易、更新了合约的状态；（实际上，这些承诺交易都是有效的交易，都是可以广播到区块链上的，只是参与者迫于惩罚，不敢再广播了）任何一方随时都可以拿对方签过名的承诺交易退出合约；但是，如果双方愿意合作，他们可以签名一笔新的交易，让双方都可以立即拿回属于自己的钱。
最后，因为承诺交易中也可置入 HTLC，所以，闪电通道也可以转发支付。假定 Alice 可以找出一条由闪电通道前后相接所组成的路径、触达 Daniel，那么无需跟 Daniel 开设通道就可以实现免信任的多跳支付。这便是闪电网络：
Alice -- HTLC --> Bob -- HTLC --> Carol -- HTLC --> Daniel
Alice <-- 原像 -- Bob <-- 原像 -- Carol <-- 原像 -- Daniel
当 Alice 找出了这样的路径并希望给 Daniel 支付时，她向 Daniel 请求一个哈希值，据以构造一个 HTLC 给 Bob，并提示 Bob 给 Carol 转发一条消息并提供相同的 HTLC；消息中又提示 Carol 给 Daniel 转发消息并提供相同的 HTLC。当消息传到 Daniel 手上时，他向 Carol 揭示原像，从而获得 HTLC 的价值、更新合约状态；Carol 也如法炮制，获得 Bob 的支付并更新通道状态；最后，Bob 向 Alice 揭示原像、更新状态。由于 HTLC 的特性，这一连串的支付要么一起成功，要么一起失败，因此，它是免信任的。
闪电网络是由一条又一条的通道组成的，每一条通道（合约）都是相互独立的。这意味着 Alice 只需知晓自己跟 Bob 的通道内发生的事情，而不必理会其他人的通道中发生了多少次交互，也不必理会这些交互使用了哪一种货币，甚至不必知晓他们是不是真的利用了通道）。
闪电网络的可扩展性不仅体现在一条闪电通道内部的支付速度仅受限于双方的硬件资源投入，还在于，由于状态的分散存储，单体节点可以用最低的成本撬动最大的杠杆。
（三）谨慎日志合约
谨慎日志合约（DLC）使用了一种叫做 “适配器签名（adaptor signature）” 的密码学技巧，使得比特币脚本可以编程出依赖于外部事件的金融合约。
适配器签名可以让一个签名仅在加入一个私钥之后，才会变成有效的签名。以 Schnorr 签名为例，Schnorr 签名的标准形式是 (R, s)，其中：
R = r.G # 签名所用 nonce 值 r 乘以椭圆曲线生成点，也可以说是 r 的公钥
s = r + Hash(R || m || P) * p # p 即为签名私钥，P 为公钥

验证签名即验证 s.G = r.G + Hash(R || m || P) p.G = R + Hash(R || m || P) PK
假设我给出了一对数据 (R, s')，其中：
R = R1 + R2 = r1.G + r2.G
s' = r1 + Hash(R || m || P) * p
显然，这并不是一个有效的 Schnorr 签名，它无法通过验签公式，但是，我却可以向验证者证明，只需 TA 知道 R2 的私钥 r2 ，就可以让它变成一个有效的签名：
s'.G + R2 = R1 + Hash(R || m || P) P + R2 = R + Hash(R || m || P) P
适配器签名让一个签名的有效性依赖于一个秘密数据，并且是可验证的。但是，这跟金融合约有什么关系呢？
假定 Alice 和 Bob 希望打赌一场球赛的结果。Alice 和 Bob 分别赌绿魔和阿林纳胜出，赌注是 1 BTC。并且，球评网站 Carol 承诺会在球赛结果揭晓时，用一个 nonce R_c 发布对结果的签名 s_c_i。
可以看出，一共有三种可能的结果（因此 Carol 的签名有 3 种可能）：
绿魔胜出，Alice 赢得 1 BTC阿林纳胜出，Bob 赢得 1 BTC平局，两人的资金原路返回
为此，两人为每一种结果创建一笔承诺交易。例如，他们为第一种结果创建的承诺交易是这样的：
输入 #0，2 BTC： Alie-Bob 2-of-2 多签名输出（即打赌合约）
输出 #0，2 BTC： Alice 单签名

但是，Alice 和 Bob 为这笔交易创建的签名却不是 (R, s)，而是适配器签名 (R, s')；也即，双方交给对方的签名都是不能直接用来解锁这个合约的，而必须揭晓一个秘密值才可以。这个秘密值，正是 s_c_1.G 的原像，也即 Carol 的签名！因为 Carol 的签名 nonce 值已经确定了（是 R_c），所以，s_c_1.G 是可以构造出来的（s_c_1.G = R_c + Hash(R_c || '绿魔胜出' || PK_c) * PK_c）。
当结果揭晓的时候，假定绿魔胜出，Carol 就会发布签名 (R_c, s_c_1)，那么无论 Alice 还是 Bob，都可以补完对手的适配器签名，再加上自己的签名，使上述交易成为一笔有效交易，并广播到网络中、触发结算效果。但如果绿魔没有胜出，Carol 就不会发布 s_c_1，这笔承诺交易也就不可能成为一笔有效交易。
以此类推，另外两笔交易也是如此。就这样，Alice 和 Bob 让这个合约的执行依赖于外部事件（准确来说是依赖于断言机对外部事件的播报，其形式是个签名），而且不需要信任对手方。大大小小的金融合约，比如期货、期权，都可以用这种方式来实现。
与其它形式的实现相比，谨慎日志合约最大的特点在于其隐私性：（1）Alice 和 Bob 不需要告知 Carol 自己正在使用 Carol 的数据，这完全不影响合约的执行；（2）链上观察者（也包括 Carol 在内），也无法通过 Alice 和 Bob 的合约执行交易来判定他们正在使用哪个网站的服务，甚至无法断定他们的合约是一个打赌合约（而不是一个闪电通道）。
四. 限制条款应用简介
（一）OP_CTV 与拥堵控制
比特币社区的开发者曾提出过多种可被归类为限制条款的提议。从当前来看，最著名的一个提议当属 OP_CHECKTEMPLATEVERIFY（OP_CTV），其概念较为简单，却保留了相当大的灵活性，因此受到崇尚简洁的比特币社区的欢迎。OP_CTV 的想法是，在脚本中承诺一个哈希值，以约束这笔资金只能被这个哈希值所表示的的交易花费；这个哈希值承诺了交易的输出以及大部分字段，但不承诺交易的输入，只承诺输入的数量。
“拥堵控制” 是一个可以体现 OP_CTV 特性的好例子。其基本应用场景是帮助大量的用户从交易所（一个需要信任的环境）退出到一个资金池中；由于这个资金池使用 OP_CTV 规划了未来的花费方式，因此它可以保证用户可以免信任地退出这个资金池，不需要任何人的帮助；又因为这个资金池只表现为一个 UTXO，它避免了在链上交易需求高涨时支付大量手续费（从 n 个输出减少到了 1 个输出；也从 n 笔交易减少到了 1 个交易）。池内用户可以伺机再从池中退出。
假设 Alice、Bob、Carol 分别想从交易所中取出 5 BTC、3 BTC 和 2 BTC。那么交易所可以制作一个带有 3 个 OP_CTV 分支的、数额为 10 BTC 的输出。假设 Alice 想要取款，她可以动用分支 1；该分支的 OP_CTV 所用的哈希值所代表的交易，将形成两个输出，一个输出是为 Alice 分配 5 BTC；另一个输出又是一个资金池，也使用 OP_CTV 承诺一笔交易，只允许 Bob 取出 3 BTC，并将剩下的 2 BTC 发送给 Carol。
Bob 或者 Carol 想要取款，也是同理。他们在取款时，将只能使用能够通过相应 OP_CTV 检查的交易，也即只能给自己支付相应的数额，而不能任意取款；剩余的资金将又进入一个使用 OP_CTV 锁的资金池，从而保证无论用户的取款顺序如何，剩余的用户都能免信任地从池中退出。
抽象地说，OP_CTV 在这里的作用是为合约规划走向合约生命终结的路径，使得这里的资金池合约不论走哪一条路径、走到了哪个状态，都能保持免信任退出的属性。
这种 OP_CTV 还有一种非常有趣的用法：“隐而不发的单向支付通道”。假设 Alice 形成了这样一个资金池，并保证资金可以免信任地退出到一个带有如下脚本的输出中：
要么， Alice 和 Bob 一起花费它要么，一段时间后，Alice 可以独自花费它
如果 Alice 不向 Bob 揭晓，Bob 就不会知道有这样的输出存在；一旦 Alice 向 Bob 揭晓，Bob 就可以把这个输出当成一个有时效性的单向支付通道，Alice 可以立即用其中的资金给 Bob 支付，而不必等待区块链的确认。Bob 只需在 Alice 可以独自花费它之前，让 Alice 给他的承诺交易上链即可。
（二）OP_Vault 与保险柜
OP_VAULT 是一种专为构造 “保险柜合约（vaults）” 而提出的限制条款提议。
保险柜合约旨在成为一种更安全、更高级的自主保管形式。当前的多签名合约虽然能免去单个私钥的单点故障，但如果攻击者真的获得了阈值数量的私钥，钱包的主人是无计可施的。保险柜希望能为资金施加单次花费的限额；同时，使用常规路径从中取款时，取款操作将强制执行一个等待期；而在等待期内，取款操作可以被紧急恢复钱包的操作打断。这样的合约，即使被攻破，钱包的主人也可以（使用紧急复原分支）发起反制操作。
理论上，OP_CTV 也可以编程出这样的合约，但却有许多的不便利，其中之一是手续费：在承诺交易的同时，它也承诺了该交易将支付的手续费。考虑到这种合约的用途，设置合约和取款的时间间隔必定很长，那就几乎不可能预测出合适的手续费。尽管 OP_CTV 没有限制输入，因此可以通过增加输入来增加手续费，但所提供的输入将全部变成手续费，因此是不现实的；另一种方式是 CPFP，也即通过花费取出的资金，在新的交易中提供手续费。此外，使用了 OP_CTV 也意味着这样的保险柜合约无法批量取款（当然也无法批量复原）。
OP_VAULT 提议则尝试通过提出新的操作码（OP_VAULT 和 OP_UNVAULT）来解决这些问题。OP_UNVAULT 是专为批量复原而设计的，我们暂时不提。OP_VAULT 的动作则是这样的：当我们把它放在脚本树的一个分支上时，它可以用来承诺一个可以动用的操作码（例如 OP_CTV）而不设具体的参数；在花费这个分支时，交易可以传入具体的参数，但不能更改其它分支。由此，它不必预设手续费，可以在花费这个分支时再设定手续费；假定这个分支也带有时间锁，那么它就会强制执行一个时间锁；最后，因为只可改变自身所在的分支，新的脚本树上的其它分支（包括紧急复原分支）不会被改变，因此允许我们打断这样的取款操作。
此外，还有两点值得一提：（1）OP_VAULT 操作码的动作类似于另一个限制条款提议：OP_TLUV ；Jeremy Rubin 正确地指出，这在一定程度上已经产生了 “计算” 的概念：OP_TLUV/OP_VAULT 先承诺了一个操作码，以允许使用者通过新的一笔交易为该操作码传入参数，从而更新整个脚本树叶子；这就已经不是 “根据一定的条件验证传入的数据” 了，而是 “根据传入的数据产生新的有意义的数据” 了，虽然它可以启用的计算是比较有限的。
（2）完整的 OP_VAULT 提议也利用了一些交易池策略（mempool policy）上的提议（比如 v3 格式的交易）以取得更好的效果。这提醒了我们 “编程” 的含义可以比我们想象的更为广泛。（一个相似的例子是 Nervos Network 里面的 Open Transaction。）
五. 理解 CKB

在上述两个章节中，我们介绍了在一种更为受限的结构（Bitcoin UTXO）上，我们如何用脚本编程出有趣的应用；也介绍了尝试为这种结构加入内省能力的提议。
UTXO 虽然不乏编程出这些应用的能力，但读者也很容易觉察出它们的缺点，或者说可以优化的地方，比如：
在 LN-Penalty 中，通道的参与者必须保存过往的每一笔承诺交易以及相应的惩罚秘密值，以应对对手的欺诈，这构成了存储上的负担。如果有一种机制，可以确保只有最新的一笔承诺交易才会生效，而旧的承诺交易无法生效，那就可以免去这种负担，而且，也可以消除节点因为故障而误将较旧的承诺交易上链，因此被意外惩罚的问题。在 DLC 中，假设事件的可能结果有很多，双方要提前生成、交给对方的签名也便有很多，这也是一种巨大的负担；此外，DLC 合约的收益是直接绑定在公钥上的，因此其仓位是不便于转移的，有没有办法可以转移合约的仓位呢？
实际上，比特币社区已经为这些问题提出了答案，基本上跟一种 Sighash 提议（BIP-118 AnyPrevOut）有关。
但是，如果我们是在 CKB 上编程，BIP-118 等于是现在就可用了（可以用内省和针对性验证签名的能力模拟出这种 Sighash 标签）。
通过学习比特币编程，我们不仅知道了 “交易输出” 这种格式下可以如何编程（CKB 能编程什么），还能知道这些应用的改进方法（如果我们在 CKB 上编程这些应用，可以如何运用 CKB 的能力来改进它们）。对于 CKB 开发者来说，简直可以将基于比特币脚本的编程当成一种学习的教材，甚至是捷径。
下面，我们逐一分析 CKB 编程的各个模块的可编程性。我们先不考虑内省能力。
（一）可编程任意计算的 Lock Script
如上所述，UTXO 是不能编程任意计算的。而 Lock Script 可以，这就意味着 Lock Script 可以编程出（限制条款部署前）基于 UTXO 编程的所有东西，包括但不限于上文所述的闪电通道和 DLC。
此外，这种可验证任意计算的能力，还使得 Lock Script 可以动用的身份验证手段比 UTXO 更多，更灵活。比如说，我们可以在 CKB 上实现一种一方使用 ECDSA 签名、另一方使用 RSA 签名的闪电通道。
实际上，这正是人们在 CKB 上最早开始探索的领域之一：将这种灵活的身份验证能力用在用户的自主保管中，从而实现所谓的 “账户抽象” —— 交易有效性的授权和控制权的恢复都非常灵活，几乎没有限制。原理上，这就是 “多种花费分支” 以及 “任意身份验证手段” 的结合。实现的例子有：JoyID Wallet、UniPass。
此外，Lock Script 也可以实现 eltoo 提议，从而实现只需保留最新一笔承诺交易的闪电通道（实际上，eltoo 可以简化一切点对点合约）。
(二）可编程任意计算的 Type Script
如上所述，Type Script 的一大用途是编程 UDT。结合 Lock Script，这意味着我们可以实现以 UDT 为标的的闪电通道（以及其它类型的合约）。
实际上，Lock Script 和 Type Script 的分割可以视为一种安全性升级：Lock Script 专注于实现保管方法或者合约式协议，而 Type Script 专注于 UDT 的定义。
此外，基于 UDT 的定义启动检查的能力，还使得 UDT 能够以跟 CKB 类似的方式参与合约（UDT is first-class citizen）。
举个例子：笔者曾经提出过一种在比特币上实现免信任 NFT 担保借贷的协议。这种协议的关键是一种承诺交易，其输入的价值是小于输出的价值的（因此它还不算是一笔有效的交易），但是，一旦能够为这笔交易提供足额的输入，它就是一笔有效的交易：一旦贷款人能够还款，放贷者就不能将质押的 NFT 据为己有。但是，这个承诺交易的免信任性基于交易对输入和输出的数额的检查，所以贷款人只能使用比特币来还款 —— 即使贷款人和放贷者都愿意接受另一种货币（比如以 RGB 协议发行的 USDT），比特币的承诺交易也无法保证只要贷款人归还了足额的 USDT 就能拿回自己的 NFT，因为比特币交易根本不知道 USDT 的状态！（修订：换言之，无法构造出以 USDT 还款为条件的承诺交易。）
如果我们能够根据 UDT 的定义发起检查，将可以让放贷者签名另一笔承诺交易，允许贷款人使用 USDT 来还款。交易将检查输入的 USDT 数量和输出的 USDT 数量，从而为用户使用 USDT 还款赋予免信任性。
修订：假定这里用作抵押的 NFT 和用于还款的 token 是使用同一套协议（比如 RGB）发行的，那么，这里的问题是能够解决的，我们可以根据 RGB 协议构造一种承诺交易，使得 NFT 的状态转换和还款可以同步发生（在 RGB 协议内用交易绑定两个状态转换）。但是，因为 RGB 的交易也要依赖于比特币交易，这里的承诺交易的构造会有一定的难度。总而言之，尽管问题可以解决，但做不到 token is first-class citizen。
接下来我们再考虑内省能力。
（三）Lock Script 读取其它 Lock Scripts
这意味着限制条款提议实施之后，比特币 UTXO 上的全部编程可能性。包括上文提到的保险柜合约，以及基于 OP_CTV 的应用（比如拥堵控制）。
XueJie 曾经提过一个非常有趣的例子：你可以在 CKB 上实现一种收款账户 Cell，在使用这种 Cell 作为交易的输入时，如果它输出的 Cell （使用相同 Lock Script 的 Cell）具备更多的 Capacity，那么这个输入无需提供签名也不会影响交易的有效性。实际上，如果没有内省的能力，这种 Cell 是无法实现的。这种收款账户 Cell 非常适合作为机构的收款方式，因为它可以将资金归集起来，缺点是它的隐私性不佳。
（四）Lock Script 读取其它 Type Scripts（以及 Data）
这种能力的一个有趣的应用是股权 Token。Lock Script 将根据其它输入中的 Token 的数量来决定能否动用自身的 Capacity，以及这些 Capacity 能够花到哪里去（需要内省 Lock Script 的能力）。
（五）Type Script 读取其它 Lock Scripts
不确定，但可以假设有用。例如，可以在 Type Script 中检查交易的输入和输出的 Lock Scripts 保持不变。
（六）Type Scirpt 读取其它 Type Scripts（以及 Data）
集换卡？集齐 n 个 token 可以换取更大的一个 token : )
六. 结论
与此前出现的可编程任意计算的智能合约系统（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些智能合约系统的了解，往往难以成为理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为受限的结构 —— BTC UTXO —— 的应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用 “内省” 的概念来理解 Cell 的 “跨合约访问” 的能力，我们可以划分运用内省能力的情形，并为它们确定具体的用途。
修订：

1. 不考虑 Cell 的交叉访问能力（即内省能力），lock scripts 可以认为是带状态、编程能力已趋极致的 Bitcoin Script，因此单凭这一点就可以编程所有基于 Bitcoin Script 的应用；

2. 不考虑 Cell 的交叉访问能力（即内省能力），lock scripts 和 type scripts 的区分可以认为是一种安全性升级：它切分了 UDT 的 资产定义 与 保管方法；此外，可暴露状态的 type scripts（以及 Data）实现了 UDT is first-class citizen 的效果。

以上两点意味着一种跟 “BTC + RGB” 相同范式但编程能力更强的东西；

3. 考虑 Cell 的内省能力，Cell 可以获得比 post-covenants BTC UTXO 更强的编程能力，并实现一些 BTC + RGB 难以实现的东西（因为 BTC 无法阅读 RGB 的状态）
关于这些用途，本文无法提出很多具体的例子，但这是因为笔者对 CKB 的生态缺乏了解的缘故。假以时日，相信人们会在其中投入越来越多的想象力，组合出如今难以想象的应用。
致谢
感谢 Retric，Jan Xie 和 Xue Jie 在文章撰写过程中提供的反馈。当然，文中所有的错误都由我自己负责。

参考文献：
1. https://forum.celestia.org/t/accounts-strict-access-lists-and-utxos/37
2. https://www.btcstudy.org/2023/07/12/covenants-in-bitcoin-a-useful-review/ 
3. https://medium.com/nervosnetwork/https-medium-com-nervosnetwork-cell-model-7323fca57571
4. https://medium.com/nervosnetwork/nervos-ckb-in-a-nutshell-7a4ac8f99e0e
5. https://xuejie.space/2019_07_05_introduction_to_ckb_script_programming_validation_model/
6. https://www.btcstudy.org/2022/09/07/on-the-programmability-of-bitcoin-protocol/#（二）谨慎日志合约（DLC）
7. https://mirror.xyz/0xbeC73ba0817403cd11C11bE891D671EA30443562/95LlE7sLCL4UTvL7rU3ZAXnBvlDbh7X-rm0QWkc43Us 
8. https://www.btcstudy.org/2021/09/07/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast/
9. https://www.btcstudy.org/2023/04/13/bitcoin-improvement-proposals-345-op-vault-commit-0b0674c546/
10. https://www.btcstudy.org/2023/06/29/tapleaf-update-verify-covenant-opcode-introduction/
11. https://www.btcstudy.org/2022/05/25/contracting-primitives-and-upgrades-to-bitcoin/
12. https://www.btcstudy.org/2022/01/27/breaking-down-the-bitcoin-lightning-network-eltoo/
13. https://github.com/btc-study/OP_QUESTION/discussions/7 

英文原文链接：https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
在当前区块链世界中，主要有两种记录保存方式，UTXO 模型（Unspent Transaction Output) 和 Account 模型。Bitcoin 采用的是 UTXO 模型，Ethereum 采用的 Account 模型。
Bitcoin 的设计初衷是点对点的电子现金系统，在比特币中，每个交易消耗之前交易生成的 UTXO 然后生成新的 UTXO，账户的余额即所有属于该地址的未花费 UTXO 集合，Bitcoin 的全局状态即当前所有未花费的 UTXO 集合。Ethereum 意图创建一个更为通用的协议，该协议支持图灵完备的编程语言，在此协议上用户可以编写智能合约，创建各种去中心化的应用。由于 UTXO 模型在状态保存以及可编程性方面的缺陷，Ethereum 引入了 Account 模型。
下面我们对两种模型的优缺点做进一步展开。
UTXO 模型

UTXO 模型中，交易只是代表了 UTXO 集合的变更。而账户和余额的概念是在 UTXO 集合上更高的抽象，账号和余额的概念只存在于钱包中。
优点：
计算是在链外的，交易本身既是结果也是证明。节点只做验证即可，不需要对交易进行额外的计算，也没有额外的状态存储。交易本身的输出 UTXO 的计算是在钱包完成的，这样交易的计算负担完全由钱包来承担，一定程度上减少了链的负担。除 Coinbase 交易外，交易的 Input 始终是链接在某个 UTXO 后面。交易无法被重放，并且交易的先后顺序和依赖关系容易被验证，交易是否被消费也容易被举证。UTXO 模型是无状态的，更容易并发处理。对于 P2SH 类型的交易，具有更好的隐私性。交易中的 Input 是互不相关联的，可以使用 CoinJoin 这样的技术，来增加一定的隐私性。
缺点：
无法实现一些比较复杂的逻辑，可编程性差。对于复杂逻辑，或者需要状态保存的合约，实现难度大，且状态空间利用率比较低。当 Input 较多时，见证脚本也会增多。而签名本身是比较消耗 CPU 和存储空间的。

Account 模型
对于 Account 模型，Account 模型保存了世界状态，链的状态一般在区块中以 StateRoot 和 ReceiptRoot 等形式进行共识。交易只是事件本身，不包含结果，交易的共识和状态的共识本质上可以隔离的。
优点：
合约以代码形式保存在 Account 中，并且 Account 拥有自身状态。这种模型具有更好的可编程性，容易开发人员理解，场景更广泛。批量交易的成本较低。设想矿池向矿工支付手续费，UTXO 中因为每个 Input 和 Out 都需要单独 Witness script 或者 Locking script，交易本身会非常大，签名验证和交易存储都需要消耗链上宝贵的资源。而 Account 模型可以通过合约的方式极大地降低成本。
缺点：
Account 模型交易之间没有依赖性，需要解决重放问题。对于实现闪电网络/雷电网络、Plasma 等，用户举证需要更复杂的 Proof 证明机制，子链向主链进行状态迁移需要更复杂的协议。
UTXO VS Account
对于以上几个优点和缺点，我们再做一些分析和对比。
第一，关于计算的问题 
UTXO 交易本身对于区块链并没有复杂的计算，这样简单的讲其实并不完全准确，原因分有两个，一是 Bitcoin 本身的交易多为 P2SH，且 Witness script 是非图灵完备的，不存在循环语句。而对于 Account 模型，例如 Ethereum，由于计算多在链上，且为图灵完备，一般计算较为复杂，同时合约安全性就容易成为一个比较大的问题。当然是否图灵完备对于是否是账户模型并没有直接关联。但是账户模型引入之后，合约可以作为一个不受任何人控制的独立实体存在，这一点意义重大。
第二，关于 UTXO 更易并发的问题 
在 UTXO 模型中，世界状态即为 UTXO 的集合，节点为了更快的验证交易，需要在内存中存储所有的 UTXO 的索引，因此 UTXO 是非常昂贵的。对于长期不消费的 UTXO，会一直占用节点的内存。所以对于此种模型，理论上应该鼓励用户减少生产 UTXO，多消耗 UTXO。但是如果要使用 UTXO 进行并行交易则需要更多的 UTXO 作为输入，同时要产生更多的 UTXO 来保证并发性，这本质上是对网络进行了粉尘攻击。并且由于交易是在钱包内构造，所以需要钱包更复杂的设计。反观 Account 模型，每个账户可以看成是单独的互不影响的状态机，账户之间通过消息进行通信。所以理论上用户发起多笔交易时，当这些交易之间不会互相调用同一 Account 时，交易是完全可以并发执行的。
第三，关于 Account 模型的交易重放问题 
Ethereum 使用了在 Account 中增加 nonce 的方式，每笔交易对应一个 nonce，nonce 每次递增。这种方式虽然意在解决重放的问题，但是同时引入了顺序性问题，同时使得交易无法并行。例如在 Ethereum中，用户发送多笔交易，如果第一笔交易打包失败，将引起后续多笔交易都打包不成功。在 CITA 中我们使用了随机 nonce 的方案，这样用户的交易之间没有顺序性依赖，不会引起串联性失败，同时使得交易有并行处理的可能。
第四，存储问题
因为 UTXO 模型中，只能在交易中保存状态。而 Account 模型的状态是在节点保存，在 Ethereum 中使用MPT 的方式存储，Block 中只需要共识 StateRoot 等即可。这样对于链上数据，Account 模型实际更小，网络传输的量更小，同时状态在节点本地使用 MPT 方式保存，在空间使用上也更有效率。例如 A 向 B 转账，如果在 UTXO 中假设存在 2 个 Input 和2个 Output，则需要 2 个 Witness script 和 2 个Locking script；在 Account 模型中则只需要一个签名，交易内容只包含金额即可。在最新的隔离见证实现后，Bitcoin的交易数据量也大大减少，但是实际上对于验证节点和全节点仍然需要针对 Witness script 进行传输和验证。
第五，对于轻节点获取某一地址状态，UTXO 更复杂
例如钱包中，需要向全节点请求所有关于某个地址的所有 UTXO，全节点可以发送部分 UTXO，钱包要验证该笔 UTXO 是否已经被消费，有一定的难度，而且钱包很难去证明 UTXO 是全集而不是部分集合。而对于 Account 模型则简单很多，根据地址找到 State 中对应状态，当前状态的 State Proof 则可以证明合约数据的真伪。当然对于 UTXO 也可以在每个区块中对 UTXO 的 root 进行验证，这一点与当前 Bitcoin 的实现有关，并非 UTXO 的特点。

结论
综上来看，Account 模型在可编程性，灵活性等方面更有优势；在简单业务和跨链上，UTXO 有其非常独到和开创性的优点。对于选择何种模型，要从具体的业务场景进行出发。

5 月 16 日晚，「极客 Web3」邀请 Bitlayer、CKB、Bool Network 的嘉宾就比特币二层的诸多问题进行了推特 Space。

以下是此次 Space 中 CKB Eco Fund 合伙人 Baiyu 分享的内容要点，摘录自「极客 Web3」的文章《对话 Bitlayer、CKB 与 Bool 网络：比特币二层不同流派大辩论》（上篇、下篇）。

Q1：怎么看当前比特币生态的发展局势？
Baiyu：我觉得趋势越来越明显。但好像感觉二级市场散户的情绪和一级市场完全是反的，就是在 CKB 我也感受到了，就是之前比特币的生态主要是公平发射，是散户在玩，没有几个正规军，然后东方的热度远高于西方，然后散户的热度远高于 VC，但是现在感觉都反过来了，首先是公平发射，如无论是 Runes 还是什么表现的好像都没有之前预期那么高。
第二点是西方，现在东方的一些 EVM 兼容的 BTC Layer2 开始上所，上所后表现不是特别好，但我们看到海外的大资本 Multicoin 还有Polychain，他们都扶持了一些 EVM 兼容的 BTC Layer2，我们知道的有 BoB、Botanix，还有最近的 Arch。
我觉得在一级市场，大家已经开始承认比特币生态在这一轮是一个贝塔级的机会，是一个很大的机会，然后都在布局，而且很多项目也都陆续要上线。这一点我觉得是很明朗的。
然后再说到整个比特币生态内部，越来越多正规军开始入场，正规军之所以会入场，前提条件是比特币生态内的逻辑一定要说得通，现在不同流派都自成一套逻辑，基本都可以站得住脚。
链上验证类型的，那就是想把以太坊 Layer2 的做法搬过来，那就依靠 BitVM，然后基于 BitVM 做OPR、ZKR，可以把以太坊 Rollup 生态的很多东西都引入进来，不会像以前某些比特币二层那么粗暴，上来就是个多签桥，未来即使是桥，也要把它尽量去中心化，即使做不到ZK级别的安全，也可以通过经济博弈来保障安全。
还有就是像 CKB，我们觉得不做链上验证的本质都是客户端验证 CSV，但不同的客户端验证方案又可以按照安全级别来划分等级，对此 CKB 有 RGB++ 的思路，还有 Lighting Labs 这样的重量级选手，他们用 Taproot Assets 发行了资产，当然这项技术还很早期。Lighting Labs 明显比之前那个非常佛系的状态积极了不少，在尝试把 Taproot Assets 发行的资产复用到闪电网络里，这跟我们的思路很像，我们也希望 RGB++ 资产进入到闪电网络。
我觉得从这个层面来讲，比特币生态是一个大的机会，其实在一级市场，在资本那里，在西方人那里，都是一个很确定的事情。我们的 UTXO Stack 最近在向西方机构融资时，收到的反馈都挺好。综合下来，我觉得比特币生态已经渐趋明朗。
Q2：BTC 二层应该满足哪些条件，有什么意义或者价值？
Baiyu：就这就是比特币生态好玩的地方，我觉得比特币 L2 没有一个明确的标准，不是 Bitcoin Magazine 说怎么样就怎么样，既然有那么多技术方案，每家的方案都有自己的侧重点，看法肯定都不一样。关于我们 CKB 的看法的话，CKB 架构师 Jan 在年初时写过一条推文，核心的观点是认为比特币生态应该是一个弹性的分层货币系统，比特币是黄金，像央行，然后它分发出来，比特币这种货币就会流入到它要去的任何地方。
所以 CEX 也算是 BTC 的二层，闪电网络也是二层，比特币可以在里面用作支付，然后侧链也是。所以我觉得，满足上述条件在某种程度上都是比特币二层，它最核心的是一个货币系统，你要承认比特币在你那是一个主要的支付工具，然后你承认这个货币的价值，这是最重要的。
其次的话，我们有一些附加的看法，我们最看重的是继承比特币的一些设计哲学，以及它的一些价值观，比如 PoW 的价值观，还有 UTXO 的设计。我们觉得，这是中本聪或者说比特币带来的最重要的一些创新，这是在此之前没有的东西。
上述特征可以带来跟比特币一层接近的体验，这在我们看来是比较重要的，其他的就是像 Liquid 那样的一些侧链，他们也是用 UTXO，并扩展了一些操作码，虽然它是联盟链，但他还是想要跟比特币一层保持某种一致性，这个是我们比较关心的。
总结下来，我们觉得比特币既然是一个货币系统，那它最好就不要像这以太坊一样频繁变化，没必要增加很多不必要的东西，尽量没有硬分叉和软分叉会更好。当然，我们可以把比特币 UTXO 当做一个染色的工具，基于此发行染色币等资产，稍微扩展一下比特币，让 BTC 可以成为一个资产发行平台，但再往前走的话，我们觉得可能会损害整个比特币系统的安全和稳固。

Q3：比特币二层的项目如果要成功，需要解决哪些问题？技术叙事是不是其中的必要条件？
Baiyu：我觉得创业需要的条件很多，本来就是一个九死一生的事情，是很偶然的事情。然后做比特币二层，其实就是做公链，做公链的话需要的东西就更多了，你不只是做一个项目，你是做一个整个生态，你还需要把它扩大，因为公链就像一个数字共同体，是一个很大的社区，这里比如治理文化等各种东西，比一般的创业更复杂。

当然，技术是非常非常重要的，没有技术的话，整个区块链行业都不存在。比特币就有很天才的设计，它发明了区块链，发明了 PoW 共识机制，把我们传送的数字化消息变成了钱，这是一个开天辟地的事情，在比特币之前都是中心化的银行系统，都是把法币映射成钱，依赖于中心化的发行方，但中本聪从 0 到 1 的创造出了 BTC 这样一种东西，这里肯定有其他学科的作用，技术是里面很核心的一点。
所以我有时候觉得，这个周期大家又向着 Web2 回归太多了，基本就是攒局搞盘子什么的，很多人应激性的说技术不重要如何如何，我不太认可这个观点，没有技术就没有 Web3，也没有办法向前进步，但是技术不应该成为各种项目在种子轮动辄几亿美元估值的正当性来源，因为这简直就像皇帝的新衣一样，我可能反对的是那种观点。
但从 CKB 团队的亲身教训来看，除了技术以外，肯定需要市场和营销，需要满足市场的需求，我觉得这也是比特币社区应该去反思的，如果比特币一直坚持它的原教旨主义，除了比特币什么币也不认，只坚持那套理想主义的意识形态，最后人们就会发现，以太坊可以搞出 EVM 和账户模型还有 PoS，然后还有一大堆的 DEX，大家都在极力满足用户的需求，最后人们反而容易忘记比特币。
但这一轮比特币生态已经开始接受这些改变，开始满足市场需求，所以我觉得除了技术以外，一定要满足用户和市场的一些需求。
Q4：比特币其实并不适合作为搭载二层的一层，它对二层造成的阻碍都体现在哪里？
Baiyu：我觉得最大的障碍是：以太坊太成功了，大家的脑子留下了很多来自于以太坊的思想钢印。当年的以太坊是很前卫的，冲破了比特币原教旨社区，告诉大家可以用区块链来做智能合约平台，然后它放弃了 UTXO，用账户模型。
虽然以太坊在当年看起来很前卫，但是经过这么多年，不得不发现以太坊上最适合做的就是金融类应用，甚至创始人也承认这是一个高度金融化的世界，好像唯一的非金融类大规模应用是 ENS，然后 ENS 当时还被 V 神一番话拉了个盘，这是最讽刺的。
目前我们要来比特币生态做建设时，还是会习惯性的把以太坊上的东西搬过来，大家在比特币生态吭哧吭哧建设，不知道什么时候就会因为以太坊既有势力的一番话而被左右。前几天我遇到一个朋友，想让他加入 CKB 的北美团队，但他在以太坊社区待了很久，他听完了我的想法后，最后问我一句话：这些东西在以太坊上都有，为什么要去比特币生态？
其实很多精英都抱有像他一样的想法，就认为比特币生态做的这些东西，以太坊都有，为什么还要去比特币？为什么还要重新再搞一套？我其实已经厌烦了听到这样的质问，所以我觉得，这一轮来说最重要的，是思考如何用比特币这个生态来做以太坊生态做不到的事情。以太坊天天改，改到最后还是 Staking，Restaking，那我们到比特币生态里还要这样搞吗？
我觉得摆脱以太坊式的思想钢印是关键，也是阻碍人才流入比特币生态的最大问题，怎么样吸引最一流的人才、最聪明的脑袋来到比特币生态建设，把区块链继续往前推进。
Q5：怎么解决提款桥的安全问题？
Baiyu：对 CKB 来说，我们把资产分两类，一类是比特币本身，一类是比特币上发行的衍生资产，比如 BRC-20 或者各种符文。我们内部研究过，比特币如果不走硬分叉或软分叉，验证能力最理想的桥接/二层方案就是 BitVM，但是 BitVM 落地还需要很长时间，所以可以认为，短期内没有密码学安全的方式让比特币安全的在一二层之间走个来回。
在这种情况下，我们觉得比特币跨链桥容易出现两个极端，要么是极端的中心化，比如说金融机构这种有牌照的托管方，比特币放他那，大户也放心，因为有法律管着。这类方案的代表其实就是 wBTC，以太坊上有应该有上百亿市值的 wBTC 对吧？是 BitGo 这个公司做的。
另一种极端的跨链桥方案就是尽量地去中心化。但桥和桥之间的区别是非常大的，大家不要一听到桥，都认为都是一样的东西，桥和桥之间的差别，甚至可以比桥和非桥的差别还大，大家一定要看清楚桥的去信任程度，这里面最终能做到的就是类似于 PoS 的模式，依靠经济上的安全措施来接近于密码学级别的安全，就是见证人如果作恶的话可以惩罚它。
但其实比特币跨链桥的各种模式，在 BTC-ETH 之间的各种跨链桥身上基本都被玩过了，大家早就想过了很多种方式，怎么把比特币搞出来，然后去到以太坊那条链上，各种方案早就被想完了，不用我们再去想其他的东西。这里面比较去中心化的方案，我看到的就是 tBTC，但 tBTC 可能没那么好用，使用面也不是特别广。
我们 CKB 其实也在跟 Bool Network 聊，看怎么合作，然后类似于 wBTC 的方案我们也在做，另外一个就是类似于 RGB++ 或者其他的类 UTXO 型资产协议，这一类资产可以通过同构绑定的方式，在 CKB 和其他 UTXO 公链之间进行免信任的来回。
至于同构绑定能不能结合 DLC，或者 BitVM 那边的一些进展让它可以在 BTC 上被验证，最后我们用 RGB++ 来发一个 RBTC，类似于 Wrapped BTC 的东西，这类方案我们正在考虑，好像有一些希望，但现在不能够下定论。
所以大家还是要注意，桥就是一个蜜罐，里面锁着那么多钱，而且里面还有一个风险，就是除了黑客攻击以外，有没有可能像 Multichain 那样，团队突然遇到不可抗阻的外力，然后钱就没了。

Q6：闪电网络和 RGB 协议都曾被寄予厚望，但是在生态建设上却差强人意，你对这点有什么看法？

Baiyu：我们最喜欢的比特币的路线，一个就是闪电网络，用 Cipher 和 Jan 的话来说，闪电网络就是比特币世界的灯塔，我们非常希望去推进闪电网络相关的东西，但是闪电网络在比特币生态建设了足足五六年，对吧？Lightning Labs 这样一个大公司在推，但进度却一直很慢，我觉得这就是比特币社区表现出的问题，所以需要更多的像 CKB 这样的鲶鱼团队出现。
我们看到 CKB 提出说要做自己的闪电网络，然后 RGB++ 可以复用到闪电网络，之后 Lighting Labs 的开发动作也加快了，我们认为闪电网络应该变得更开放，而不是把话语权集中在少数的中心化公司手里，而是成为一个开放的标准，它可以去兼容比特币一层上任意一种符合标准的 UTXO 资产。但 Lighting Labs 现在更多的是在自己做 Taproot Assets，然后闪电网络的基础设施会先去兼容 Taproot Assets 这样的东西，没有完全变得开放。
我们希望比特币生态可以继续促进闪电网络等技术标准的开放性，在我们看来，他目前是 To B 更多而不是直接 To C，大量用户忍受不了闪电网络的操作体验，而后者为了安全牺牲掉了 UX 上的便利。要便利就要让渡一些安全性，有很多类似于金融机构的服务商就存活于闪电网络的生态中，我们可以看到，这类机构在安全性上就做出了一些妥协，但他的产品便利性很好，比如 LSD，在方案设计中还考虑了关于合规的东西，这些就是我了解到的关于闪电网络的进展。
然后 CKB 自己的闪电网络大概是 6 月中旬会上测试网，然后会开始一些测试，期待大家来测试我们一些东西。我们希望闪电网络加上 RGB++，再加上 JoyID 这样的 PassKey 钱包，可以真正的让人们大规模地用起来。
关于第二个话题 RGB 的话，我觉得我们讨论它的时候，不如直接讨论它包含的那两样东西，一个是 CSV（客户端验证），这是比特币社区非常重要的扩容思路。但很遗憾的是，CSV 被埋没了，没怎么被讨论，更多人还是想用以太坊的思路做比特币的扩容，但做比特币的扩容时，不是在比特币链外再搞一条链，而是在链外搞一个 P2P 网络。
比特币社区最讲究的核心，在我看来是 P2P，是点对点的连接，让我们相互之间直接验证重要的东西。CSV 基本上就是这样一个思路，就是我在比特币链外再构建一个 P2P 网络，大家可以自发的、两个人彼此之间就能够验证转账的有效性。为了做到这一点，还有一个核心概念，就是一次性密封，用比特币链上的 UTXO 做 Single-Use Seal。
上述两点是 RGB 协议最核心的两点，可以做很多很多文章，CSV 你可以把它看作一个服务，然后你可以做一个 dApp 形态的 CSV 平台，CSV 可以用 as a service 的形式去做。当然 CKB 基于 RGB 做的最核心的事，就是做了 RGB ++，我们把 CKB 当做 RGB 在链外的一个客户端，通过同构绑定就可以保证安全。
其实还有一个比较大胆的想法，就是基于比特币做 CSV 可能不是最好的选择，因为比特币的验证能力有限，但你可以在 CKB 上去做 CSV，包括在 CKB 上结合 Nostr 去做一些事情。我们这几天可能就会发布一个技术方案，就是说 Nostr 怎么结合 CKB，然后鼓励很多项目方来做一些社交相关的东西。
总而言之，我总结一下，大概就是比特币社区有 RGB 的思路，有闪电网络的思路，这些都是比特币社区非常优秀的协议，应该被发扬光大，结合这些东西就可以做出我前面提到的以太坊上做不到的东西。以太坊当年是想做闪电网络的，如果是进圈早的人，应该知道以太坊有一个东西叫雷电网络，后来做着做着就不做了，完全放弃掉了，但这是比特币能做的事情，那我们为什么不沿着这个方向继续往下走呢？
而且据我所知，以太坊那边也有一些项目在做 CSV 客户端验证的事情，但这些东西其实都来自于比特币社区，所以我们是可以把它发扬光大的。
其实当今的闪电网络已经不是单纯用来小额支付的了，现在没有人会用比特币去做支付了，大家还是把它用作资产存储，而且散户手里没有多少比特币，真正可能的场景是，我觉得闪电网络会成为一个基础设施，会去兼容在比特币上发行的各种资产协议。
比如说你用 RGB++ 去发行 USDT，然后这个 USDT 可以进到闪电网络，所以闪电网络更像一个高速路，你可以让其他的车子也进去，原来里面只有一种车就是比特币，现在可以让其他车也进去，这是它最大的一个变化。
第二点我觉得比较重要的是，比特币的闪电网络还是非图灵完备的，但是在 CKB 上闪电网络可以去加一些条件，起码可以让闪电网络里兼容多种资产协议，然后你就可以完成 swap，甚至你可以在闪电网络里面做 DeFi，这里面想象空间很大。

Q7：比特币二层想要达到以太坊二层的体量，还有多少问题要解决？
Baiyu：我觉得大家其实放低了对比特币生态的预期，以太坊生态发展了很多年，然后探索出来了适合其技术架构的应用，但比特币生态还需要更长的时间来构建出繁荣的生态，所以会站在以太坊的肩膀上，在生态建设上会对其有一些借鉴，我觉得这是重要的一点。
当然，我们还要围绕着比特币原有的一些东西去探索，比如说 UTXO 到底可以做什么？比如说我们在探索 UTXO 是否更适合去做 NFT 相关的东西，因为它本来就是并行化的，而且是用户个人拥有的，不是被智能合约所拥有的资产。
然后在 DeFi 赛道里看 UTXO，其计算流程是在比特币链下做计算，在链下做完了计算后把结果放到链上去验证，链下计算—链上验证这样的技术架构，更适合做 intent 和 order book，做 order book 型交易平台最早就是以太坊的想法，但他们的 order book 做得不理想，最后出来的是 AMM 自动化做市商，但在比特币生态这边未必是这样。这些都需要更长的时间去摸索，然后需要走向市场。

Q8：在当前的比特币二层生态中，哪些项目方在技术或者是综合叙事上，是你比较欣赏的？
Baiyu：我最欣赏的当然就是 RGB 和 RGB++ 代表的 CSV 路线，和闪电网络这样一个快速支付的路线，这两个路线有一个特点都是在链外扩容，然后在一定程度上依赖比特币 UTXO 的安全性以及比特币脚本很有限的能力，这是比特币生态里很独特的东西。
我们总是想把比特币改的像以太坊一样，比如智能合约的验证能力，然后可以做很多很多的事情。大家会一直在链下探索怎么搞更多的东西。然后我也是希望更多的团队可以探索出创新之路，我们总是羡慕一个 Uniswap 出来了， 500 行代码就可以写出一个 Uniswap，但其实在 Uniswap 之前也有其他的 DeFi 协议，还有更多的人做了很多尝试，最后才有 Uniswap 跑出来。
我觉得现在比特币生态也处在这样一个前夕，就是有大量的创新想法，各种 idea，但是并没有被大家完全意识到，或者把它产品化推向市场，其实可以找到很多这样的机会，这就是我的看法。

CKB 社区成员Retric提出 Nostr Binding Protocol
原文发表在 Github https://github.com/RetricSu/nostr-binding/blob/main/docs/lightpaper-zh.md

在这篇文章里，我们提出了一种协议，将 Nostr 协议中的基本数据结构绑定到 CKB 区块链上。通过这种绑定，我们允许 Nostr 原生数据继承 CKB 区块链上 UTXO/Cell 的特性，为 Nostr 协议带来了基于链上机制的新的可能性。一个潜在的用例是在 Nostr 上发行原生资产。Nostr 绑定协议也为 dApp 带来了一种新的开发范式。与将你的 dApp 分成两个系统不同（一个是链下服务器，另一个是链上智能合约），我们使用一个具有不同数据级别的一致系统来构建 dApp。这与以太坊的模式有根本不同。

Web5 的三层结构:
关于 Nostr
Nostr 是一种简单且开放的信息分发协议，它使用中继-客户端模型在全球网络中分发标准消息。中继-客户端模型类似于区块链中的 P2P 网络，但更便宜、更灵活、更实用(也更集中化)，更适合用来打造消费级应用的大规模采用。标准消息是 Nostr 的核心创新。Nostr 基于 JSON 定义了一种标准的消息格式(这个消息格式同时也是协议的基本数据结构)，用于描述各种不同的数据。它被称为"Event"。
Event 结构:

Event 是一个包含任意内容并由用户签名的数据片段，因此可以在客户端进行验证，而无需信任任何中继服务器。你在 Nostr 协议中发布的所有消息都是不同种类和要求的 Event。你可以从 NIPs 了解更多关于 Nostr 的信息。
关于 CKB
CKB 是比特币的二层网络，具有类 UTXO 和 POW 的设计。CKB 的基本数据结构称为 Cell。Cell 是一种具有强大可编程性的通用 UTXO。
Cell 结构:

Script结构:

你可以从 docs.nervos.org 了解更多关于 CKB 的信息。
绑定
所谓的绑定，就是在 Nostr Event 和 CKB Cell 之间创建一对一的映射关系。Event 用于定义你资产的详细信息，而与这个 Event 互相映射的 Cell 则用于提供所有权的保护和其他区块链特定的能力。要创建这种一对一映射，你需要让一个 Nostr Event 指向一个 CKB Cell，反之亦然。由于 Nostr 和 CKB 协议的简单性，创建这种绑定非常容易。
我们需要的只是两个 Script
我们在 Nostr 绑定协议中引入了两个 CKB Script。第一个是 Nostr binding Script，它是一个 Type Script，定义了从 Nostr 协议的 Event 绑定到 CKB 上的方法。它是一个非常简单的 Script，但涵盖了绑定的核心逻辑。第二个是 Nostr lock Script，一个使用 Nostr Event 作为解锁签名的 Lock Script。它用于简化用户体验和构建基于 CKB 的 Nostr dApp 的过程。
Nostr binding Script
Nostr binding Script是一个Type Script，用于定义从 Nostr 协议的某些特殊 Event 绑定到链上的规则。Nostr binding Script 确保使用该 Script 作为 Type Script的 Cell 是 CKB 区块链中唯一存在的一个与特定的 Nostr Event 绑定的 live Cell。
binding Script:

TYPE_ID 用于确保区块链中只有一个 live Cell 具有这种 type hashNOSTR_EVENT_ID 用于确保该 Cell 只指向一个唯一的 Nostr Event
使用 Nostr binding Script 作为 Type Script的 Cell 是 Nostr Event 的绑定 Cell。
Nostr 绑定的 Event 结构:

cell_type_id 标签在 Nostr 资产 Event 中确保该 Event 只指向一个唯一的 CKB Cell
Nostr 资产 Event 呈现了用户铸造的资产。Nostr 资产元数据 Event 用于描述同一资产集合的元数据。
Nostr 资产元数据 Event 结构:

Nostr Lock Script
Nostr lock Script 是一个使用 Nostr Event 作为解锁证明的 Lock Script。它用于简化用户体验和构建基于 CKB 的 Nostr dApp 的过程。
Nostr lock Script结构:

args 设置为 Nostr 账户的公钥。你也可以在最后 4 个字节中添加一个 POW 值，这意味着解锁 Event 必须满足一定的 POW 难度。当 args 是 32 个字节全为 0 时，意味着没有人可以解锁该锁。当前 32 个字节全为 0，最后 4 个字节是非零值时，意味着该锁可以被任何 Nostr 账户解锁，只要解锁 Event 满足一定的 POW 难度值(这可用于公平发行)
Nostr 解锁 Event 结构:

要解锁使用 Nostr lock Script的 CKB Cell，必须在交易的 witness 字段中提供一个 Nostr 解锁 Event。用户可以生成多个解锁 Event，但由于 Event 在上传到链时会在标签中记录相应的 CKB 交易，剩余的 Event 将自动失效，因此不会有重放风险。
Nostr lock Script也可以支持多重签名。它的lock Script args 可以是一个 Nostr Event ID。该 Event 的 Tag 字段记录了所有所有者 M 个 P 公钥。解锁需要至少 N 个（N<=M）Nostr 账户提供 Nostr unlock Event 作为证明。
有了 Nostr lock Script的帮助，用户可以使用 Nostr 生态客户端和浏览器插件直接签名并生成解锁的 Event 作为签名证明来解锁 CKB 交易，因此这些链下 Nostr 生态工具的开发者可以尽可能少地了解和引入 CKB 与区块链相关的代码。同时，用户几乎可以"不关心"区块链。项目方或其他志愿者可以运行一个特殊的中继，监控 Nostr 网络中是否有新的解锁 Event，如果有，就帮助解析交易并提交到 CKB 链进行解锁。交易费用可以通过预留部分余额作为手续费的 Cell 来支付。
发行资产
直接绑定
用户:需要 Nostr 账户和 CKB
索引 CKB Cell 并计算该 Cell 的 TYPE_ID使用 TYPE_ID 生成带有 Nostr 签名的 Nostr 资产 Event使用 Nostr 资产 Event 生成 CKB 绑定交易，并发送到链上
通过 RGB++
用户:需要 Nostr 账户、比特币钱包和聪
索引 UTXO，通过 RGB++ 生成映射 Cell，并计算该 Cell 的 TYPE_ID使用 TYPE_ID 生成带有 Nostr 签名的 Nostr 资产 Event使用 Nostr 资产 Event 生成 CKB 绑定交易，并发送到链上
转账
使用 Nostr 锁定时
用户:需要 Nostr 账户
在 CKB 上索引你想要解锁的使用 Nostr lock Script的 Cell构造一个 CKB 交易，用其他lock Script替换这个 Cell使用第 2 步的结果，通过 Nostr 客户端/浏览器扩展生成 Nostr 解锁 Event将 Nostr 解锁 Event 发送到一个特殊的中继组，并提交到链上
使用其他锁定时
用户:需要拥有对应其他锁定的钱包，无需任何 Nostr 相关操作
只需按照 CKB/RGB++ 上的正常流程解锁转账即可。
可扩展性问题
Nostr 绑定协议的主要优势是非常简单直接。简单性也使客户端开发者更容易在其之上构建产品。另一方面，Nostr 绑定协议的缺点是可扩展性问题。在这种简单设计下，Nostr token 的吞吐量与 CKB 区块链绑定，因此 CKB 区块链将成为瓶颈。考虑到 Nostr 作为一个更灵活的社交网络，旨在大规模采用，当未来有大量用户与这些原生资产交互时，这种吞吐量可能会成为问题。
然而，我们看到了一些解决这个问题的选择:
与 CKB 闪电网络集成
由于 Nostr 绑定协议创建的 Nostr 原生资产可以被视为普通的 CKB 资产，因此一旦 CKB 闪电网络推出，我们可以利用它来扩展 Nostr 绑定协议。Nostr 绑定协议本身不需要任何更改，这是一个免费的功能。但缺点是需要等待 CKB 闪电网络推出。
实现简单但有用的支付通道
在 CKB 闪电网络推出之前的另一种选择是实现一些非常简单但有用的支付通道，如 spillman 通道。spillman 通道是一种单向支付通道，实现更简单。通道中有一个付款人和一个收款人。对于区块链来说，这种支付通道可能不太有用，但在 Nostr 绑定协议的情况下，它非常适合内容创作者与他们的关注者之间的订阅模式。
N 对 1 绑定而不是 1 对 1 绑定
与创建 1 对 1 绑定不同，我们可以在 Nostr Event 和 CKB Cell 之间创建 N 对 1 绑定。换句话说，我们将多个事件捆绑到一个单元格中，以实现可扩展性。这将使链上映射存储成本比链下 Nostr Event 小得多。但是，N 对 1 绑定的问题在于，它需要设计一种新的模式来控制和拆分捆绑事件的所有权。这将更加复杂，需要额外的设计和实现工作。
RGB 风格解决方案
实现最终可扩展性的另一种方式是创建一种 RGB 风格的解决方案，将 CKB Cell 用作一次性密封，并使 Nostr 协议成为类似 RGB 协议的实现层。这种解决方案可以选择只实现代币标准，而排除原始 RGB 协议中的通用智能合约理念，从而简化工作流程。
常见问题解答
为什么选择 Nostr?
Nostr 是基于加密技术的大众级应用的理想层。它是一种超级简单、直接、实用、不带偏见且易于集成的信息分发协议。许多 web3 项目可能会使用类似 Arweave 和 IPFS 的东西，它们持有完全不同的价值观和理念。你可以将 Nostr 视为一种超级松散的协议，没有对完全去中心化的 P2P 网络的执着，也没有长期存在于 web3 世界中对代币经济和激励机制的过度承诺，这使得 Nostr 更加实用和不带偏见。
为什么不直接使用区块链资产?
让用户能够基于 Event 在 Nostr 网络中发行自己的原生资产，而不是在 Nostr 网络中直接使用现有的区块链代币，主要是基于这样一个简单的事实：如果没有创造价值，代币就没有意义。对于消费级产品，大多数区块链资产只会在产品工作流程中带来阻力，而不会为产品增加价值。与其将代币机制强加到产品中，不如从用户角度出发，看看他们需要什么，区块链能提供什么帮助。我们认为基于 Event 的原生资产符合这种方法论。应用开发者和用户可以从自己的角度看看他们能用资产做什么，而不是强制他们接受现有的区块链资产和规则。此外，基于 Event 的资产更容易与 Nostr 协议无缝协作，为现有的 Nostr 生态系统产品和工具带来了新的玩法。
为什么选择 CKB?
由于 CKB 的可编程性，使用 CKB 实现绑定协议要容易得多。比特币就更难了。此外，考虑到 CKB 与 BTC 绑定的独特方式，通过先与 CKB 绑定，再与 BTC 绑定会更容易。
结语
总的来说，Nostr 作为一种简单实用的信息分发协议，非常适合消费级应用的大规模采用。而 CKB 的可编程性和与比特币的绑定关系，使其成为实现 Nostr 绑定协议的理想选择。同时，基于 Nostr Event 发行原生资产，可以从应用出发设计新的产品机制，从而让 Nostr 与其他传统互联网应用进行竞争，寻找自己独特的 PMF。

《10 分钟快速入门 RGB++ 协议及其玩法》一文用通俗易懂的语言介绍了 RGB++ 协议的相关知识，RGB++ 的现有生态及其玩法，目的是希望能帮助大家快速入门和上手。而 JoyID 钱包是目前对 RGB++ 资产提供最全面支持的加密钱包，因此，精通 JoyID 的使用对于深入参与 RGB++ 生态尤为重要。
本文将精选 JoyID Passkey Wiki 中的部分内容，帮助大家快速入门和上手 JoyID 钱包。
JoyID 钱包简介
1、什么是 JoyID 钱包？
JoyID 是结合 Passkey 密钥管理的加密钱包。无需记住密码或复杂的助记词，只需十秒，用户就能创建一个非托管的加密钱包账户，无感进入 Web3 世界。
作为一种基于 FIDO WebAuthn 协议 并利用 Nervos CKB 构建的网络钱包解决方案，JoyID 用户能够在几秒钟内开设账户，并使用 Face ID 和 Touch ID 等安全账户体系管理自己的钱包。在 JoyID 中，用户无需下载安装，同时还可以访问多个区块链网络并实现多设备登录，获得流畅无感的用户体验。
2、JoyID 钱包的主要特点
无需密码和助记词：通过生物识别即可访问钱包，确保其他人无法进入你的钱包。多设备支持：跨手机（安卓/苹果）、笔记本电脑或任何链接设备无缝交易。备份和恢复：提供多种备份方加强账户安全，并支持多设备轻松备份、恢复账号。多链支持：不仅支持 BTC 和 Nervos CKB，JoyID 也支持 ETH 和一系列 EVM 链。简单易上手：无论你是加密小白还是加密 OG， JoyID 是你与各种 dApp 轻松进行交互的最佳选择。
3、JoyID 的内置功能
JoyID 不仅仅是一个钱包，现在还支持一些内置功能：
Spore DOBs Market：首个 DOBs 交易市场
JoyID 推出了第一个 DOBs（数码物）交易市场。DOBs 基于链上数字资产协议 Spore Protocol 开发，其内在价值由锁定的 CKB 代币支持；DOB 需要的链上存储空间越大，其锁定的 CKB 就越多。用户现在可以在 JoyID 市场上交易 Unicorn Box 等 DOBs。
Coins: RGB++ 资产 DEX
Coins 是一个支持 RGB++ FT 资产交易的 DEX，你可以在 Market 页面点击 Coins 即可访问。无 Gas 费，无交易费，用户即可体验丝滑交易在比特币二层（即 CKB 区块链）上的 RGB++ 资产。
JoyID 钱包的使用
1、JoyID 支持什么设备/系统？
Android：必须是版本 7 或更高，并配备 Google Mobile Service；支持 Chrome，Firefox，Edge。iOS：需要 iOS 版本 16 或更高，并启用 iCloud 服务；支持 Safari，Chrome，Firefox，Edge。macOS：必须是 macOS Catalina 或更高版本，支持 Touch ID；支持 Safari，Chrome，Edge。
注意，以下环境不支持创建 JoyID 账户：Windows 系统，MIUI with second space，鸿蒙系统，Firefox on macOS。
如果你的设备满足这些规格，但你仍然无法注册，请在 webauthn.me 进行测试以检查 WebAuthn 支持，并通过在 JoyID 的 Discord 服务器上创建工单来寻求帮助。
2、JoyID 要在哪里下载?
JoyID 是一个浏览器钱包，无需下载安装 app，点击 app.joy.id 即可访问。
3、如何备份你的 JoyID 账户？
第一步：进行账户升级
在旧设备中通过 app.joy.id 访问你需要备份的账户。通过右上角设置按钮标识，打开 Security，点击 “+”，点击 Upgrade 付费进行升级。升级需花费 150 CKB，请确保钱包账户余额超过 250 CKB。升级成功后，你可以点击 CKB 余额，查看会显示 150CKB 被占用。
第二步：账户备份
访问待备份的 JoyID 账户，通过旧设备的右上角设置按钮标识，打开 Security，点击 “+”。获得授权二维码/链接：a. 通过新设备扫描二维码并通过浏览器打开（推荐 Chrome）b. 复制 URL 到新设备的浏览器中打开（推荐 Chrome）在新设备中访问授权链接，验证两次后，生成 Passkey。注意：整个备份过程中，请保持旧设备处于亮屏状态，保证备份能顺利进行。旧设备授权，完成备份，并查看备份状态。
更多内容和视频教程，请查看 JoyID 备份多设备教程：
https://www.notion.so/JoyID-106a01fcb60b4934b982022a623e8292?pvs=21
4、如何多开 JoyID 账户？
登录 app.joy.id 页面，点击 Create New，生物识别进行两次验证，以创建新的通行密钥，点击 Confirm ，新的账户便创建成功。
5、如何使用 JoyID 钱包对 RGB++ 资产进行拆分？
对于在比特币链上的 RGB++ 资产，如果是 FT，可以通过以下方式进行资产拆分：
登录 JoyID 钱包，切换至 BTC 网络，选择你想要拆分的 RGB++ 资产（比如 SEAL）。点击 Send，然后发送到自己的 BTC 地址，Amount 一栏填写你想拆分成的数量。点击确认并进行签名。查看交易状态，当所有的状态都完成后，拆分成功。可以前往 HueHub 查看拆分的资产并进行挂单交易操作。
6、如何将比特币链上的 RGB++ 资产 Leap 到 CKB 链上？
JoyID 钱包已经支持了 RGB++ 资产的 Leap 功能。登录 JoyID 后，切换至 Bitcoin 网络，然后点开你的 RGB++ 资产（比如 SEAL），在发送界面选择 Bitcoin L2（CKB） 并输入 CKB 地址、数量，选择矿工费，最后点击 Send 并进行签名确认。
视频教程如下：
https://x.com/joy_protocol/status/1780505146067448176 
需要特别说明的是，为了保证安全性（防止区块重组），整个 Leap 的过程需要等待大约 1 小时。完成 Leap 后，RGB++ 资产就在 CKB 区块链上了，就可以使用 JoyID 钱包内置的 DEX 或者 Omiga 的 Marketplace 进行交易了。

FAQ
1、手机丢了，如何找回我的 JoyID 账户？
如果你有另一个设备登录或备份，你的资产仍然安全，直接使用另外一台设备登录即可。
如果你之前启用了 Passkey，你的资产仍然安全，它会在同一个 iCloud 或 Google 账户上的设备间同步。使用生物识别在新设备上访问 JoyID，在登录页面选择使用 Passkey 登录。
2、为什么提示 Passkey 不存在，或者在此设备上没有发现通行密钥？
如果出现该提示，意味着你在该设备下的账户由于重置过设备 Pin 码/锁屏密码/系统升级导致丢失，请根据以下步骤判断是否可找回：
已经做过账户升级备份，此情况可以用另外一台设备恢复。没有做过账户升级备份，但是可以在 Google Account / iCloud 账户里，找到 JoyID 的 Passkey，可以通过尝试登录 Google Account/ iCloud 进行恢复，在登录时，请确保该设备能访问谷歌/苹果服务。通过 CKB 地址恢复。对于部分机型，用户可以返回登录界面，通过 CKB 地址进行恢复。
如果你尝试过上面几种方法都无法恢复账户，意味着你的账户已丢失。
3、在什么情况下我的钱包会丢失或者无法登录？
如果你没有做任何备份，以下情况会导致你的钱包丢失/无法登录，并无法找回：
重置设备的锁屏密码 / PIN 码，该操作会导致账户无法恢复/找回。前往备份的 Google Account / iCloud 账号里删除 JoyID Passkey，该操作会导致账户无法恢复/找回。使用浏览器创建 JoyID 账户，但没有开启 Passkey Backup，而后清除浏览器缓存。
关于 JoyID 的更多知识，欢迎查阅 JoyID Passkey Wiki：
https://www.notion.so/nervina/ca5b5cd04d7e4fd3899ce6c65b334fcc?v=1bbdc0e710c44b7997033dfa7bf8de06&pvs=4 
最后，如果你在使用 JoyID 钱包的过程中，遇到了其他无法自行解决的问题，可以前往 JoyID 的 Discord 服务器创建工单来寻求帮助：
https://discord.com/invite/77MyakRKVB 

从 4 月初部署到比特币主网到现在，不到一个月的时间，通过 RGB++ 协议发行的加密资产已经超过了 300 多种，首个 RGB++ 资产 $SEAL 的持币地址数则达到了 16850，累计交易额超过 180 $BTC 。

除此之外，RGB++ 的生态发展也开始初具规模，钱包、浏览器、DEX、Launchpad、资产管理器等必要的基础设施都可以使用。
然而，还是有很多人对 RGB++ 协议及其玩法不够了解，想参与却不知道从哪里开始。所以，今天这篇文章将分为 3 个部分，第一部分用通俗易懂的语言介绍 RGB++ 协议的相关知识，第二部分介绍 RGB++ 的生态及其玩法，第三部分是 FAQ，希望能帮助大家快速入门和上手。

RGB++ 协议的基础知识
1、RGB++ 协议是什么？它和 RGB 协议是一样的吗？和最近上线的 Runes 协议有什么区别？

RGB++ 协议和 RGB 协议是两个完全不同的协议。RGB++ 协议的作者是 Cipher，他也是 $CKB 的联合创始人，而 RGB 协议目前主要是 Maxim Orlovsky 博士在主导。
RGB++ 的定位是比特币一层资产发行协议，这就意味着你可以使用 RGB++ 协议在最安全、共识最强的比特币区块链上发行加密资产。发行完资产后，你把资产转给其他人，接收方不需要自己运行客户端做验证，这是因为通过 RGB++ 协议发行的资产，会在 CKB 区块链上生成对应的影子资产。如果拿肉身和影子作为类比，在比特币区块链上转账 RGB++ 资产，相当于肉身发生了转移，其对应的影子也会跟着移动，而影子的移动会有 CKB 区块链的 PoW 矿工进行验证。所以，我们可以相信，只要影子的移动是正确的，那对应的肉身转移也是正确的（当然，你也可以选择不信任 CKB 矿工，选择自己去验证肉身的转移是否正确）。
Runes 协议和 RGB++ 一样，都属于比特币一层资产发行协议，但当下并没有太多的竞争，因为整个市场的盘子很小，大家一起把蛋糕做大才是最重要的。目前 Runes 还缺乏可编程性，如果和 RGB++ 合作，会带来双赢的效果：RGB++ 可以为 Runes 带来可编程性，而 Runes 可以为 RGB++ 带来更多的关注度。
2、比特币链上太堵且手续费太贵了，RGB++ 协议有什么解决方案？
在铸造 RGB++ 资产时，会同时在比特币区块链和 CKB 区块链生成交易，比特币链上的交易用来塑造资产的肉身，CKB 上的交易用来生成对应的影子。所以，在铸造时，用户需要花费更多的 BTC 手续费（因为有一小部分用来购买 CKB 和生成对应的影子了）。
铸造好资产后，如果嫌比特币链上太堵和手续费太高，可以把资产的肉身 Leap 到 CKB 区块链上，这样肉身和影子就都在 CKB 链上了。CKB 平均出块时间约为 10 秒，手续费也非常低廉，一枚 CKB 正常情况下可以支付 5000 多次转账所需的矿工费。所以，Leap 到 CKB 区块链的 RGB++ 资产，可以享受 CKB 带来的高速高性能，可以在 CKB 上完成几千次、几万次的转账后再 Leap 回到比特币区块链。
此外，CKB 区块链是图灵完备的，可以在上面搭建各类 DeFi 和 GameFi 应用。这意味着 Leap 到 CKB 区块链的 RGB++ 资产也可以参与这些应用，赚取更多收益，实现更广的应用场景。

3、Leap 操作是啥？它是跨链桥吗？
不是的，RGB++ 资产从比特币区块链 Leap 到 CKB 区块链或者反向操作，并没有使用任何跨链桥或者引入外部的信任假设。
常见的跨链桥，是大家把加密资产打给某个多签钱包或者合约，然后在另外一条链给你发相应的资产凭证。它的缺陷是偏中心化，而且用户得信任跨链桥的运营方不会作恶。如果跨链桥被黑客攻击了，用户的资产可能会遭受损失：2021 年 7 月跨链资产桥项目 ChainSwap 遭到攻击，损失了近 800 万美元的资产；2022 年 1 月，Qubit Finance 跨链桥遭到黑客攻击，损失超过 8000 万美元；2022 年 2 月，Wormhole 被黑客攻击，损失超过 3.2 亿美元......
Leap 是点对点地把资产从一条区块链转移到另外一条区块链，它会更加安全，也更加去中心化。

RGB++ 的生态和玩法
RGB++ 的生态
RGB++ 协议于 4 月初部署到了比特币主网，目前已经实现了协议本身所要涵盖的核心功能，包括 fungible、non-fungible 资产的发行、转让，还有 leap 操作，SDK 等。
RGB++ 的生态发展也开始初具规模：
钱包：JoyID、REI Wallet（插件钱包）等DEX：HueHub、Omiga、JoyID 内置的 DEX 等，还有即将上线的 AMM  DEXLaunchpad：HueHubDID：.bitDeFi：Stable++（稳定币协议）知名项目：Nervape、SEAL 等其他：Haste（RGB++ 资产管理工具）、Metaforo（支持 RGB++ 协议的投票治理工具）等

RGB++ 的玩法
1、如何发行 RGB++ 资产？
目前，大家可以直接使用 HueHub 来发行 RGB++ 资产。
打开 HueHub 网站（https://huehub.xyz），连接钱包（UniSat、OKX 或者 JoyID）并确保钱包里有足够的 BTC，点击「Issue a RGB++ token」，然后填写 RGB++ 资产的代币名称、符号、总供应量、每次 mint 的数量以及几个比特币区块后开始 mint 等信息，填写完后提交并支付 BTC 手续费即可，非常简单易操作。

2、如何 mint 他人发行的 RGB++ 资产？
如果他人发行的 RGB++ 资产有专门的 mint 网站，可以直接打开相应的网站并参照指示完成铸造。
第二种是打开 HueHub 的 Fair Mint 页面（https://huehub.xyz/fair-mint），连接钱包，找到你想要 mint 的资产，点击旁边的 mint 按钮进行铸造。
3、如何交易 RGB++ 资产？
如果你想交易在比特币一层上的 RGB++ 资产，可以直接使用 HueHub 的 Marketplace，买的话就在 Market 中点击「Buy Now」，卖的话就选择「List for sale」。
如果你想交易在比特币二层（即 CKB 链上）的 RGB++ 资产，目前有多个选择。一个是使用 JoyID 钱包内置的 DEX，可在钱包的「Market」中看到；另一个是使用 Omiga 的 Marketplace（https://omiga.io/market）。这两个 DEX 都是订单簿模式的，同时社区团队成员也在做基于 AMM 的 DEX，预计会在不久的将来推出

4、如何将比特币链上的 RGB++ 资产 Leap 到 CKB 链上？
JoyID 钱包已经支持了 RGB++ 资产的 Leap 功能。登录 #JoyID 后，切换至 Bitcoin 网络，然后点开你的 RGB++ 资产（比如 SEAL），在发送界面选择「Bitcoin L2（CKB）」并输入 CKB 地址、数量，选择矿工费，最后点击「Send」并进行签名确认。视频教程如下：
https://x.com/joy_protocol/status/1780505146067448176需要特别说明的是，为了保证安全性（防止区块重组），整个 Leap 的过程需要等待大约 1 小时。完成 Leap 后，RGB++ 资产就在 CKB 区块链上了，就可以使用 JoyID 钱包内置的 DEX 或者 Omiga 的 Marketplace 进行交易了。
5、如何将 CKB 链上的 RGB++ 资产 Leap 到比特币链上？
JoyID 钱包目前的版本还未支持该功能，需要再等待一段时间，预计 5 月底之前会上线。
另外，目前并不建议大家使用社区成员做的一些工具来进行 Leap 操作，因为容易发生资产被烧掉的事情（将在下文具体介绍）。

1、在铸造 RGB++ 资产或者转账 BTC 时，为什么 mempool 中没有显示？
其中一个原因是节点没有完成广播，这种情况比较常见，如果是这个原因，多等一段时间即可。
另一个原因是交易手续费设置得太低了。挖矿节点会按交易的手续费从高到低排队，优先打包那些手续费高的，如果手续费太低，过了一定时间，比如三天，还没有轮到它的话，挖矿节点一般会把这样的低手续费交易从自己的内存池里删除掉。任何节点删了你的交易，它们并不会通知你的钱包，交易也不会被退回，你的钱包也不可能自动显示你发送交易之前的余额。如果是这种情况，只能使用一些矿池推出的 “交易加速处理服务”，需要额外支付费用。
2、为什么 RGB++ 资产会被烧掉?
通过 RGB++ 协议发行的资产，它 “寄生” 或者说 “绑定” 在比特币的 UTXO 中，更具体地说，是绑定在大小为 546 聪的 UTXO 中。如果这个 UTXO 被花费了，那对应的 RGB++ 资产也会被花费掉。
那怎么避免绑定了 RGB++ 资产的 UTXO 被用户误花费掉呢？JoyID 钱包设置了一个阈值，目前这个阈值是 1200 聪，低于这个阈值的 UTXO 不会被当作矿工费或者是普通的 BTC 转账而花费掉。当然，不同的钱包设置的阈值不一样，因此为了避免被误花费掉，建议大家使用 JoyID 钱包来存储和收发 RGB++ 资产。
前文有提到，目前并不建议大家使用社区成员做的一些工具来将资产从 CKB 链上 Leap 到比特币链上，这是因为有些工具在绑定比特币 UTXO 的时候并没有遵循 RGB++ 的标准 —— 绑定到 546 聪的 UTXO 上，如果他们把资产绑定到了超过 1200 聪的 UTXO 上，那用户在使用 JoyID 钱包发送 BTC 交易时，钱包就很容易会把这个 UTXO 当作矿工费或者是普通的 UTXO 花费掉。
3、既然 JoyID 钱包在 RGB++ 生态中扮演了那么重要的角色，那我应该如何提高钱包的安全性呢？
JoyID 钱包目前的版本还不支持助记词备份，所以为了防止误删钱包或者误删 Passkey，建议大家一定要做账户升级，升级后可以关联多个不同品牌的设备。
登录 JoyID 钱包后，在设置中，选择「Security」，点击「Trusted Devices」旁边的「+」号，点击「Upgrade」，然后支付 150 CKB 或者其他数量的其他代币，即可完成账户升级。升级完成后，点击「Trusted Devices」旁边的「+」号，就可以添加不同品牌的设备了，比如苹果手机创建的 JoyID 钱包可以添加安卓手机作为备用登录设备。
关于 JoyID 钱包的更多知识，欢迎阅读：
https://nervina.notion.site/JoyID-FAQ-2fcae5726fee4c298f6e5efdb2d1ed3d