上周，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) とアカウント モデルという 2 つの主要な記録保持方法があります。ビットコインはUTXOモデルを使用し、イーサリアムはアカウントモデルを使用します。
ビットコインはもともとピアツーピアの電子キャッシュ システムとして設計され、各トランザクションは前のトランザクションによって生成された UTXO を消費し、その後、アカウントの残高はそのアカウントに属するすべての未使用の UTXO のセットになります。ビットコインのグローバル状態は、現在使用されていないすべての UTXO の集合です。イーサリアムは、ユーザーがスマート コントラクトを記述し、さまざまな分散型アプリケーションを作成できるチューリング完全プログラミング言語をサポートする、より一般的なプロトコルを作成する予定です。 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

前言

第 4 轮比特币减半周期中，#Ordinals 协议以及类似协议的爆发式采用，让加密行业意识到基于比特币 L1 层发行资产与交易资产对比特币主网共识安全和生态发展的正外部性价值，可谓是比特币生态的 “Uniswap 时刻”。
比特币可编程性的进化与迭代，是比特币社区意见市场治理的结果，而非为了 BTC 的 Holder、为了区块空间的 Builder 等目的论所驱动的。
当下，通过增强比特币的可编程性进而增加比特币主网区块空间的使用率，成为比特币社区共识的新设计空间。
与以太坊和其它高性能公链不同，为了保证 UTXO 集的简洁性和轻量化，比特币可编程性的设计空间是高度受限的，基本约束在如何使用脚本和 OP Code 操作 UTXO。
经典的比特币可编程性方案有状态通道（闪电网络）、客户端验证（RGB）、侧链（Liquid Network、Stacks、RootSock等）、CounterParty、Omni Layer、Taproot Assets、DLC 等等。2023 年以来新兴的比特币可编程性方案有 Ordinals、BRC20、Runes、Atomicals、Stamps 等等。
在铭文第二波浪潮结束之后，新一代比特币可编程性方案等等纷纷涌现，如 #CKB 的 #UTXO #同构绑定 方案、EVM 兼容比特币 L2 方案、DriveChain 方案等等。
与 EVM 兼容比特币 L2 方案相比，CKB（Common Knowledge Base）的比特币可编程性方案，是比特币可编程性现代设计空间中一个原生的、安全的、不引入社会信任假设的解决方案。而与 DriveChain 方案相比，它不要求比特币协议级别的任何变动。
在可预计的未来，比特币可编程性的成长曲线将经历一个加速增长阶段，比特币生态的资产、用户、应用将随之迎来一波玄武纪大爆发，CKB 生态的 UTXO Stack 将为新涌入的比特币开发者提供利用模块化堆栈构建协议的能力。另外，CKB 正在探索将闪电网络与 UTXO Stack 集成，利用比特币的原生可编程性实现新协议之间的互操作性。

比特币可编程性的命名空间

区块链是创造信任的机器，比特币主网是其中的 0 号机。像西方所有哲学都是对柏拉图的注脚一样，加密世界里的一切事物（资产、叙事、区块链网络、协议、DAO 等等）都是比特币的派生物和衍生品。
在比特币 Maxi 与扩容主义者的协同进化过程中，从比特币主网是否支持图灵完备之争到隔离见证方案与大区块扩容方案之争，比特币在不断分叉。这既在创生新的加密项目和加密社区共识，也在强化和巩固比特币自身的社区共识，这是一个在他者化的同时完成自我确认的过程。
由于中本聪的神秘消失，比特币社区治理并不存在以太坊那样的 “开明君主专制” 的治理结构，而是由矿工、开发者、社区和市场进行开放博弈达到均衡的治理模型。这赋予比特币的社区共识一旦形成、异常稳固的特性。
目前比特币社区共识的特性有：共识不是命令和控制、信任最小化、去中心化、抗审查性、伪匿名性、开源、开放协作、免许可、法律中立、同质化、向前兼容性、资源使用最小化、验证 > 计算、收敛、交易不可变性、抗 DoS 攻击、避免争抢进入、稳健性、激励一致、固化、不该篡改的共识、冲突性原则、协同推进等。[1]
目前的比特币主网形态，可以看作是以上比特币社区共识特性的实例化结果。而比特币可编程性的设计空间，也是由比特币社区共识特性所定义的。
比特币可编程性的经典设计空间

在其他公链尝试模块化、并行化等等方案探索区块链不可能三角解决方案的设计空间时，比特币协议的设计空间一直聚焦在脚本、OP Code 和 UTXO。
典型的两个实例，分别是 2017 年以来比特币主网的两次重大升级：Segwit 硬分叉和 Taproot 软分叉。
2017 年 8 月的 Segwit 硬分叉，在 1M 的主区块外新增 3M 的区块专门保存签名（见证，Witness），并在计算矿工费时将签名数据的权重设为主区块数据的 1/4，以保持花费一个 UTXO 输出和创建一个 UTXO 输出成本的一致性，防止出现滥用 UTXO 找零增加 UTXO 集膨胀速度的情况。
2021 年 11 月的 Taproot 软分叉，则通过引入 Schnorr 多重签名方案，节省 UTXO 的验证时间和多重签名所占的区块空间。

1 个 UTXO 的键值组（图源：learnmeabitcoin.com）
UTXO（未花费的交易输出）是比特币主网的基础数据结构，它具有原子性、非同质性、链式耦合的特性。比特币主网上的每一笔交易，都会消耗掉 1 笔 UTXO 作为输入，同时创建整数 n 个新的 UTXO 输出。通俗点理解，UTXO 可以视作运行在链上的美元、欧元等纸币，它可以花费、找零、拆分、组合等等，只不过它的最小原子单位是聪（sats）。1 笔 UTXO 就代表某个特定时间的 1 个最新状态。UTXO 集，即代表某个特定时间比特币主网的最新状态。
通过保持比特币 UTXO 集的简洁性、轻量化和易验证性，比特币主网的状态膨胀速度成功稳定在与硬件摩尔定律相适应的水平，从而保障比特币网主网全节点的可参与性和交易验证的鲁棒性。
与之相应的，比特币可编程性的设计空间同样受到比特币社区共识特性的约束。例如，为了防范潜在的安全风险 ，中本聪在 2010 年 8 月决定将 OP-CAT 操作码移除，而该操作码是实现比特币图灵完备级别可编程性的关键逻辑。
比特币可编程性的实现路径，没有采用以太坊、Solana 那样的链上虚拟机（VM）方案，而是选择利用脚本和操作码（OP Code）对 UXTO、交易的输入字段、输出字段和见证数据（Witness）等进行编程操作。
比特币可编程性的主要工具箱有：多重签名、时间锁、哈希锁、流程控制（OP_IF，OP_ELIF）。[2]
经典设计空间下，比特币可编程性是非常有限的，仅仅支持几种验证程序，而不支持链上状态存储和链上计算，而链上状态存储和链上计算恰恰是实现图灵完备级可编程性的核心功能组件。

比特币可编程性的文艺复兴
但比特币可编程性的设计空间，并不是一个固定不变的状态。相反，它更接近一种随着时间变化的动态光谱。
与外界对比特币主网开发陷入停滞状态的刻板印象不同，在各种共识向量局限设计空间的情况下，比特币主网新脚本和新操作码的开发、部署、采用、推广始终处在进行时态，并在某些时间甚至引发过加密社区的分叉战争（如 Segwit 硬分叉）。
以比特币主网脚本类型采用度变迁为例，我们可以清晰地感知到其中的变化。比特币主网输出类型使用的脚本，我们可以划分为3大类：
原初脚本：pubkey、pubkeyhash增强脚本：multisig、scripthash见证脚本：witness_v0_keyhash、witness_v0_scripthash、witness_v1_taproot

比特币主网全历史输出类型；来源：Dune
从比特币主网全历史输出类型的变化趋势图中，我们观察一个基本的事实：比特币主网可编程性增强是长期历史趋势，增强脚本在吞噬原初脚本的份额，而见证脚本在吞噬增强脚本的份额。基于 Segweit 增强脚本和 Taproot 见证脚本的 Ordinals 协议所开启比特币 L1 资产发行浪潮，既是比特币主网可编程性历史趋势的延续，也是比特币主网可编程性的新阶段。
比特币主网操作码也有着与比特币主网脚本类似的演进过程。
例如 Ordinals 协议，就是通过结合比特币主网脚本 taproot script-path spend 和操作码（OP_FALSE、OP_IF、OP_PUSH、OP_ENDIF）实现其功能设计。

Ordinals 协议的 1 次铭刻实例

在 Ordinals 协议正式诞生之前，比特币可编程性的经典方案，主要有状态通道（闪电网络）、客户端验证（RGB）、侧链（Liquid Network、Stacks、RootSock等）、CounterParty、Omni Layer、DLC 等等。
Ordinals 协议将 UXTO 的最小原子化单位聪（Satoshi）序列化，再将数据内容铭刻在 UTXO 的 Witness 字段，并与序列化后的某一特定聪相关联，然后由链下索引器负责索引和执行这些数据状态的可编程性操作。这种新的比特币可编程性范式，被形象地比喻为 “黄金上雕花”。
Ordinals 协议的新范式，激发了更大范围的加密社区使用比特币主网区块空间发行、铸造和交易 NFT 收藏品和 MeMe 类型 Token（可统称为铭文）的热情，其中有很多人在人生中第一次拥有自己的比特币地址。
但 Ordinals 协议的可编程性，继承了比特币的可编程性的有限性，仅支持 Deploy、Mint 和 Transfer 三种功能方法。这让 Ordinals 协议以及它的跟随者 BRC20、Runes、Atomicals、Stamps 等等协议，只适用于资产发行的应用场景。而对需要状态计算和状态存储的交易和借贷等 DeFi 应用场景的支持，则比较乏力。

Ordinals 协议 3 种类型的 TX 数量（图源：Dune）
流动性是资产的生命力来源。由于 Ordinals 类型比特币可编程性协议的天然特性，导致铭文资产重发行而轻流动性提供，进而影响到一个铭文资产全生命周期产生的价值。
而且 Ordinals、BRC20 协议还有滥用见证数据空间的嫌疑，并在客观上造成比特币主网状态爆炸。

比特币区块空间大小变化（图源：Dune）
作为参照系，以太坊主网 Gas 费的主要来源为 DEX 交易 Gas 费、L2 的数据可用性费和稳定币转账 Gas 费等。与以太坊主网相比，比特币主网的收入类型单一、周期性强、波动率大。
比特币主网的可编程性能力，尚不能满足比特币主网区块空间供给侧的需求。而达到以太坊主网稳定且可持续的区块空间收入状态，需要比特币生态原生的 DEX、稳定币和 L2。而实现这些协议和应用的前提条件，是比特币可编程协议需要提供图灵完备的编程能力。
因此，如何原生地实现比特币图灵完备的可编程性，同时约束对比特币主网状态规模的负面影响，成为比特币生态的当前一个显学。
比特币可编程性的CKB方案
目前实现比特币原生的图灵完备的可编程性的方案要有：BitVM、RGB、CKB、EVM 兼容 Rollup L2、 DriveChain 等等。
BitVM 使用比特币的一组 OP Code 构建与非逻辑门，再通过与非逻辑门构建其他基础逻辑门，最终由这些基础逻辑门电路构建出一个比特币原生的 VM。这个原理，有点类似著名科幻小说《三体》的秦王阵列图。Netflix 改编的同名电视剧里有具体的场景呈现。BitVM 方案的论文已经完全开源，备受加密社区的期待。但它的工程实现难度非常大，遇到链下数据管理成本、参与方数量限制、挑战-响应交互次数、哈希函数复杂度等等问题，短期内很难落地。
RGB 协议使用客户端验证和一次性密封技术来实现图灵完备的可编程性，核心设计思想是将智能合约的状态和逻辑存储在比特币交易（Transaction）的输出（Output）上，将智能合约代码的维护和数据存储放在链下执行，由比特币主网作为最终状态的承诺层。
EVM 兼容 Rollup L2，是快速复用成熟的 Rollup L2 堆栈构建比特币 L2 的方案。但鉴于比特币主网目前无法支持欺诈证明/有效性证明，Rollup L2 需要引入社会信任假设（多签）。
DriveChain 是一种侧链扩展方案，基本设计思想是将比特币作为区块链的底层，通过锁定比特币来创建侧链，从而实现比特币和侧链之间的双向互操作性。DriveChain 工程的实现，需要对比特币进行协议级别改动，即将开发团队提议的 BIP300、BIP301 部署到主网。
以上比特币可编程性方案要么工程难度极大短期难以落地，要么引入过多社会信任假设，要么需要对比特币进行协议级别改动。
比特币 L1 资产协议：RGB++
针对以上比特币可编程性协议存在的不足和问题，CKB 团队给出了一个相对均衡的解决方案。该解决方案由比特币 L1 资产协议 RGB++、比特币 L2 Raas 服务商 UTXO Stack 和与闪电网络集成的互操作协议组成的。
UXTO 原生的原语：同构绑定
RGB++，是基于 RGB 设计思想开发的比特币 L1 资产发行协议。RGB++ 的工程实现，同时继承了 CKB 和 RBG 的技术原语。它有使用 RGB 的 “一次性密封” 和客户端验证技术，同时通过同构绑定将比特币 UTXO 映射到 CKB 主网的 Cell（扩展版的 UTXO），并使用 CKB 和比特币链上的脚本约束来验证状态计算的正确性和所有权变更的有效性。
换言之，RGB++ 是用 CKB 链上的 Cell 表达 RGB 资产的所有权关系。它把原本存放在 RGB 客户端本地的资产数据，挪到 CKB 链上用 Cell 的形式表达出来，与比特币 UTXO 之间建立映射关系，让 CKB 充当 RGB 资产的公开数据库与链下预结算层，替代 RGB 客户端，实现更可靠的数据托管与 RGB 合约交互

RGB++ 的同构绑定（图源：RGB++ Protocol Light Paper ）

Cell 是 CKB 的基本数据存储单元，可以包含各种数据类型，如 CKBytes、代币、TypeScript 代码或序列化数据（如 JSON 字符串）。每个 Cell 都包含一个小程序，称为 Lock Script，它定义了 Cell 的所有者。Lock Script 既支持比特币主网的脚本，如多签、哈希锁、时间锁等，也允许包含一个 Type Script 来执行特定的规则，以控制其使用。这使开发人员能够根据不同的用例定制智能合约，例如发行 NFT，空投代币、AMM Swap 等等。
RGB 协议通过使用 OP RETURN 操作码将链下交易的状态根附加到一个 UTXO 的 output，将该 UTXO 作为状态信息的容器。然后，RGB++ 将这个由 RGB 构建的状态信息容器映射到 CKB 的 Cell 上，将状态信息保存在 Cell 的 type 和 data 中，将这个容器 UTXO 作为 Cell 状态所有者。

RGB++ 交易生命周期（图源：RGB++ Protocol Light Paper ）

如上图所示，一个完整的 RGB++ 交易生命周期如下：
链下计算。当发起 1 笔同构绑定的 Tx 时，要首先选择比特币主网的一个新的 UTXO btc_utxo#2 作为一次性密封的容器，再在链下对原 Cell 同构绑定的 UTXO btc_utxo#1、新 Cell 同构绑定的 btc_utxo#2、以原 Cell 作为输入新 Cel 作为输出的 CKB TX 进行哈希计算生成一笔承诺。提交比特币交易。RGB++ 发起一笔比特币主网的 Tx，将与原 Cell 同构绑定的 btc_utxo#1 作为输入，使用 OP RETURN 将上一步生成的那笔承诺作为输出。提交 CKB 交易。在 CKB 主网执行之前链下计算生成的 CKB Tx。链上验证。CKB 主网运行一个比特币主网轻客户端验证整个系统的状态变更。这点与 RGB 非常不同，RGB 的状态变更验证采用的 P2P 机制，需要 Tx 的发起方与接收方同时在线且只对相关的 TX 图谱进行交互式验证。
基于以上同构绑定逻辑实现的 RGB++，与 RGB 协议相比，在让渡部分隐私性的同时，获得了一些新特性：区块链增强的客户端验证、交易折叠、无主合约的共享状态和非交互式转账。
区块链增强的客户端验证。RGB++ 允许用户选择采用PoW维持共识安全 CKB 验证状态计算和 URXO-Cell 的所有权变更。交易折叠。RGB++ 支持将多笔 Cell 映射到单笔 UTXO 上，从而实现 RGB++ 的弹性扩展。无主智能合约和共享状态。UTXO 状态数据结构实现图灵完备智能合约的一大困难，就是无主智能合约和共享状态。RGB++ 可以利用 CKB 的全局状态 Cell 和意图 Cell 解决这一问题。非交互式转账。RGB++ 将 RGB 的客户端验证流程变成可选项，不再强制要求交互式转账。用户选择 CKB 验证状态计算和所有权变更的话，交易的交互体验与比特币主网保持一致。

此外，RGB++还继承了 CKB 主网 Cell 的状态空间私有化特性，RGB++ 每笔 TX 除了支付使用比特币主网区块空间的矿工费之外，还需要额外支付租赁 Cell 状态空间的费用（这部分费用在 Cell 消费之后原路返回）。Cell 的状态空间私有化，是 CKB 发明的一种应对区块链主网状态爆炸的防御机制，Cell 状态空间的租赁者在使用期间需要持续的付费（以被 CKB 流通代币通胀的形式稀释价值）。这使得 RGB++ 协议是一种负责任的比特币主网可编程性扩展协议，在一定程度上能够限制对比特币主网区块空间的滥用现象。
去信任的 L1<>L2 互操作：Leap
RGB++ 的同构绑定，是一种共时性的原子实现逻辑，要么同时发生，要么同时翻转，不存中间状态。所有的 RGB++ 交易都会在 BTC 和 CKB 链上同步各出现一笔交易。前者与 RGB 协议的交易兼容，后者则取代了客户端验证的流程，用户只需要检查 CKB 上的相关交易即可验证这笔 RGB++ 交易的状态计算是否正确。但用户也可以不使用 CKB 链上的交易作为验证依据，利用 UTXO 的局部相关 Tx 图谱，独立地对 RGB++ 交易进行验证（交易折叠等部分功能仍然需要依赖 CKB 的区块头哈希做防双花验证）。
因此，RGB++ 与 CKB 主网之间的资产跨链，并不依赖引入额外的社会信任假设，如跨链桥的中继层、EVM 兼容 Rollup 的中心化多签金库等等。RGB++ 资产可以原生的、去信任的从比特币主网转移到 CKB 主网，或者从 CKB 主网转移到比特币主网。CKB 将这个跨链工作流称之为 Leap。
RGB++ 与 CKB 之间是松耦合的关系。除了支持比特币 L1 层的资产（不限于 RGB++ 协议原生资产，包括采用 Runes、Atomicals、Taproot Assets 等协议发行的资产）Leap 到 CKB 之外，RGB++ 协议还支持 Leap 到 Cardano 等其他 UTXO 图灵完备链。同时，RGB++ 还支持比特币 L2 资产 Leap 到比特币主网。

RGB++ 的扩展功能和应用实例

RGB++ 协议原生支持发行同质化代币和 NFT。
RGB++ 的同质化代币标准是 xUDT ，NFT 标准是 Spore 等。
xUDT 标准支持多种同质化代币发行方式，包括但不限于集中分发、空投、订阅等。代币总量还可以在无上限和预设上限之间进行选择。对于预设上限的代币，可以使用状态共享方案来验证每次发行的总数是否小于或等于预设上限。
NFT 标准中的 Spore，会在链上存储所有元数据，实现了 100% 的数据可用性安全。Spore 协议发行的资产 DOB（Digital Object，数码物），类似于 Ordinals NFT，但是有更加丰富的特性和玩法。
作为客户端验证协议，RGB 协议天然支持状态通道和闪电网络，但受限于比特币的脚本计算能力，把 BTC 之外的资产去信任引入进闪电网络非常困难。但 RGB++ 协议可以利用 CKB 的图灵完备脚本系统，实现基于 CKB 的 RGB++ 资产的状态通道和闪电网络。
有了以上标准和功能，RGB++ 协议的用例不像其他比特币主网可编程协议那样局限在简单的资产发行场景，而支持资产交易、资产借贷、CDP 稳定币等复杂应用场景。例如，RGB++ 同构绑定逻辑结合比特币主网原生的 PSBT 脚本，可以实现一种订单簿网格形态的 DEX。

比特币 L2 RaaS 服务商：UTXO Stack

UTXO 同构比特币 L2 vs EVM 兼容比特币 Rollup L2
在图灵完备的比特币可编程性实现方案市场竞争中，DriveChain、恢复OPCAT 操作码等方案由于需要比特币协议层的变更，需要的时间和成本具有非常大的不确定性和不可预测性， 现实主义路线中的 UTXO 同构比特币 L2 和 EVM 兼容比特币 Rollup L2 更受到开发者和资本的认可。UTXO 同构比特币 L2，以 CKB 为代表。EVM 兼容比特币 Rollup L2，以 MerlinChain 和 BOB 为代表。
实事求是地讲，比特币 L1 资产发行协议在比特币社区中刚刚开始形成局部共识，比特币 L2 的社区共识度则处在更早期。但在这个前沿领域，《比特币杂志》和 Pantera 已经尝试通过借鉴以太坊 L2 的概念结构为比特币 L2 设定定义范围。
在他们眼中，比特币 L2 应该具有以下 3 点特性：
使用比特币作为原生资产。比特币L2必须将比特币作为其主要的结算资产。使用比特币作为结算机制来强制执行交易。比特币L2的用户必须能够强制返回其在一层资产控制权（可信或不可信）。展示对比特币的功能依赖性。如果比特币主网失效但比特币L2系统仍然可保持运行，那么该系统不是比特币的L2。[4]

换言之，他们认为的比特币 L2 应该具有基于比特币主网的数据可用性验证、逃生舱机制、BTC 作为比特币 L2 Gas 代币等。这样看来，在他们潜意识中，是将 EVM 兼容 L2 范式作为比特币 L2 的标准模板。
但比特币主网薄弱的状态计算和验证能力在短期内无法实现特性 1 和特性 2，在这种情况情况下 EVM 兼容 L2 属于完全依赖社会信任假设的链下扩展方案，尽管它们在白皮书写着未来集成 BitVM 进行数据可用性验证和与比特币主网联合挖矿增强安全性。
当然，这并不意味着这些 EVM 兼容 Rollup L2 是假的比特币 L2，而是它们没有在安全性、去信任性和可扩展性之间做到很好的平衡。而且比特币生态引入以太坊的图灵完备解决方案，易被比特币 Maxi 视作对扩容主义路线的绥靖。
因此，UTXO 同构比特币 L2 天然在正统性和比特币社区共识程度上优于 EVM 兼容 Rollup L2。
UTXO Stack 的特性：分形比特币主网
如果说以太坊 L2 是以太坊的分形，那么比特币 L2 理应是比特币的分形。
CKB 生态的 UTXO Stack 为开发者一键启动 UTXO 比特币 L2，并原生集成 RGB++ 协议能力。这使得比特币主网和使用 UTXO Stack 开发的 UTXO 同构比特币 L2 之间，可以通过 Leap 机制实现无缝互操作。UTXO Stack 支持质押 BTC、CKB 以及 BTC L1 资产来保障 UTXO 同构比特币 L2 的安全。

UTXO Stack 架构（图源：Medium）

UTXO Stack 目前支持 RGB++ 资产在比特币闪电网络——CKB 闪电网络——UTXO Stack 平行 L2 们之间自由流转和互操作。除此之外，UTXO Stack 还支持 Runes、Atomicals、Taproot Assets、Stamps 等基于 UTXO 的比特币 L1 可编程性协议资产在 UTXO Stack 平行 L2 们——CKB 闪电网络——比特币闪电网络之间自由流转和互操作。
UTXO Stack 将模块化范式引入到比特币 L2 的构建领域中，用同构绑定巧妙绕过了比特币主网状态计算和数据可用性验证问题。在这个模块化堆栈中，比特币的角色是共识层和结算层，CKB 的角色是数据可用性层，而 UTXO Stack 平行 L2 们的角色是执行层。

比特币可编程性的成长曲线与CKB的未来
比特币可编程性的成长曲线与 CKB 的未来
事实上，比特币的数字黄金叙事与比特币的可编程叙事之间内在的紧张关系，比特币社区中一些 OG 将 23 年以来兴起的比特币 L1 可编程协议视作对比特币主网的新一轮粉尘攻击热潮。某种程度上，比特币核心开发者 Luke 与 BRC20 粉丝之间的口水战，是继支持图灵完备与否之争、大小区块之争之后，比特币 Maxi 与扩容主义者的第三次世界大战。
但其实存在另一种视角，将比特币视作数字黄金的 APP Chain。在这种视角下，正是数字黄金的底层去中心化账本这一定位，形塑了如今的比特币主网 UTXO 集形态和可编程协议特性。但如果我没记错的话，中本聪愿景是想让比特币成为一种 P2P 电子货币。数字黄金对可编程性的需求是保险箱和金库，货币对可编程性的需求是中央银行-商业银行的流通网络。所以说比特币的可编程性增强协议并不是离经叛道的行为，而是回归中本聪愿景。

比特币是第一个 AppChain （图源：@tokenterminal）

我们借鉴 Gartner Hype Cycle 的研究方法，可以将比特币可编程性方案们划分为 5 个阶段
技术萌芽期：DriveChain、UTXO Stack、BitVM 等期望膨胀期：Runes、RGB++、EVM Rollup 比特币 L2 等泡沫破灭期：BRC20、Atomicals 等稳步复苏期：RGB、闪电网络、比特币侧链等成熟高原期：比特币脚本、Taproot 脚本、哈希时间锁等
CKB 的未来：比特币生态的 OP Stack+EigenLayer
无论是 EVM 兼容比特币 Rollup L2，还是 UTXO 同构比特币 L2，亦或者是 DriveChain 等新范式，图灵完备可编程性的诸种实现方案，最终都指向比特币主网作为共识层和结算层。
正如趋同进化在自然界一再发生那样，可以预期比特币生态图灵完备可编程性的发展趋势将在某些方面与以太坊生态呈现一定程度的一致性。但这个一致性，又不会是简单复刻以太坊的技术堆栈到比特币生态，而是利用比特币原生的技术栈（以 UTXO 为基础的可编程性）实现相似的生态结构。
CKB 的 UTXO Stack 与 Optimism 的 OP Stack 的定位非常相似，OP Stack 是在执行层保持与以太坊主网的强等效性和一致性，UTXO Stack 则是在执行层保持与比特币主网的强等效性和一致性。同时，UTXO Stack 与 OP Stack 结构一样，都是平行结构。

CKB 生态现状（图源：CKB 社区）
未来 UTXO Stack 将推出共享序列器、共享安全性、共享流动性、共享验证集等 RaaS 服务，进一步降低开发者启动 UTXO 同构比特币 L2 的成本和难度。目前已经有一大批去中心化稳定币协议、AMM DEX、 借贷协议、自主世界等项目，计划采用 UTXO Stack 构建 UTXO 同构比特币 L2 作为其底层共识基础设施。
与其他比特币安全性抽象协议不同，CKB 的共识机制是与比特币主网一致的 PoW 共识机制，由机器算力维持共识账本的一致性。但 CKB 的代币经济学与比特币存在一些区别。为保持区块空间生产和消耗行为激励的一致性，比特币选择引入权重和 vByte 机制计算状态空间使用费，CKB 则选择将状态空间私有化。
CKB 的代币经济学由基础发行和二级发行两部分组成。基础发行的所有 CKB 完全奖励给矿工，二级发行的 CKB 的目的收取状态租金，二级发行的具体分配比例取决于当前流通的 CKB 在网络中的使用方式。
举个例子，假设所有流通的 CKB 中，有 50% 用于存储状态，30% 锁定在 NervosDAO 中，20% 完全保持的流动性。那么，二级发行的 50% （即存储状态的租金）将分配给矿工，30% 将分配给 NervosDAO 储户，剩余的 20% 将分配给国库基金。
这种代币经济模型能够约束全局状态的增长，协调不同网络参与者（包括用户、矿工、开发者和代币持有者）的利益，创建一个对每个人都有利的激励结构，这与市场上其他 L1 的情况有所不同。
此外，CKB 允许单个 Cell 占用最大 1000 字节的状态空间，这赋予了 CKB 上的 NFT 资产一些其他区块链同类资产不具有奇异特性，比如原生携带 Gas 费、状态空间的可编程性等等。这些奇异特性，使得 UTXO Stack 非常适合作为自主世界项目的基础设施来构建数字物理现实。
UTXO Stack 允许比特币 L2 开发者使用 BTC、CKB 以及其他比特币 L1 资产质押参与其网络共识。
总结

比特币发展到图灵完备的可编程方案阶段，是不可避免的。但图灵完备的可编程性，不会发生在比特币主网，而是发生在链下（RGB、BitVM）或者比特币 L2 上（CKB、EVM Rollup、DriveChain）。
按照历史经验，这些协议上将有 1 条协议最终发展成为垄断性的标准协议。
决定比特币可编程性协议竞争力的关键因子有二：1. 不依赖额外社会信任假设的实现 BTC 在 L1<>L2 之间的自由流转；2. 吸引足够规模的开发者、资金和用户进入其 L2 生态。
CKB 作为比特币可编程性解决方案，利用同构绑定+CKB 网络替代客户端验证的解决方案，实现了比特币 L1 层资产在 L1<>L2 之间的自由流转，且不依赖额外社会信任假设。而且受益处于 CKB Cell 的状态空间私有化特性，RBG++ 并没有像其他比特币可编程性协议那样给比特币主网带来状态爆炸的压力。
近期，通过 RGB++ 首批资产发行初步完成了生态的热启动，为 CKB 生态成功 onboard 了约 15 万新用户和一批新开发者。如比特币 L1 可编程性协议 Stamps 生态的一站式解决方案 OpenStamp，已选择使用 UTXO Stack 构建服务于 Stamps 生态的 UTXO 同构比特币 L2。

下一阶段，CKB 将重点放在生态应用建设、实现 BTC 在 L1<>L2 之间的自由流转、集成闪电网络等方面，力争成为未来的比特币的可编程性层。

文章中提到的部分链接：
[1] https://nakamoto.com/what-are-the-key-properties-of-bitcoin/
[2] https://www.btcstudy.org/2022/09/07/on-the-programmability-of-bitcoin-protocol/#一-引言
[3] https://medium.com/@ABCDE.com/cn-abcde-我们为什么要投资utxo-stack-91c9d62fa74e
[4] https://bitcoinmagazine.com/technical/layer-2-is-not-a-magic-incantation 

ChainCatcher 消息，BiFi 新协议 UTXOSwap 发布轻皮书并计划于 5 月下旬开启公测。UTXOSwap 团队在 Bitcoin Devcon 黑客松比赛中获得 #CKB 生态第一名，现已与 CKB Eco Fund 达成战略合作。
据悉，UTXOSwap 是一个基于 CKB 的去中心化交易（DEX）协议，旨在定义 Bitcoin Finance 交易新范式。UTXOSwap 采用以意图为中心的交易模式，利用 UTXO 编程模型的优势。目前支持 RGB++ 和 CKB 生态资产的交易，并计划未来扩展到包括 Ordinals、Runes 在内的其他 BTC 生态资产。

UTXOSwap 实现了基于意图的混合交易模型，同时支持自动做市商（AMM）机制和链外订单簿（Order book）撮合。此外，利用 CKB 底层技术，如密码源语等链级设计，UTXOSwap 具备 Swap 交易几乎 0 Gas 且可使用任意代币支付、支持用户自定义 AMM 曲线和手续费率、以及 dApp 原生兼容多链钱包和L1/L2 无感操作等优势。
以下内容来自《UTXOSwap 轻皮书》，原文链接：
https://utxoswap.gitbook.io/zh

UTXOSwap 轻皮书：
定义 Bitcoin Finance 交易新范式

UTXOSwap 概述

UTXOSwap 是基于 BTC 生态的去中心化交易所（DEX）协议，旨在通过基于意图的（Intent-based）交易为用户提供更优质的交易体验和更好的成交价格。目前 UTXOSwap 会支持 RGB++ 和 CKB 生态的资产进行交易，未来还将扩展支持 Runes 等其他 BTC 生态资产。

目前常见的 DEX 主要有订单簿（Order book）和自动化做市商（AMM）两种形式，其中订单簿 DEX 受限于链上交易的高成本，并没有获得像中心化交易所那样的成功，AMM 则凭借其简单直接的交易理念获得了更为广泛的认可。然而，随着链上交易量和流动性的爆发，AMM 的问题也逐渐显现，比如效率低下，gas fee 竞争，MEV 横行等。于是，基于意图的（Intent-based）交易模型开始出现，它融合了订单簿和 AMM 的优势，让用户和做市商的体验和效益最大化。UTXOSwap 正是采用了基于意图的模式作为其核心，利用 UTXO 编程的优势全新设计的 DEX。
得益于 UTXO 的特性，UTXOSwap 有很多创新和优势：在交易模式上，UTXOSwap 能够做到链下撮合、链上验证，从而在撮合阶段可以接入 AMM 之外的流动性供应商；在性能上，UTXO 的并行特点也能让交易效率获得成倍地提升；在 gas fee 上，没有成交的意图不会产生 gas fee，正常成交的 gas 也低到可以忽略不计，如果有的交易对过于火爆，还可以采用 local fee 的模式隔离它们对其他交易对的影响。
UTXOSwap 是 BTC 生态非常重要的基础设施，能够很好地解决目前 BTC 生态资产流动性差、交易成本高的问题，降低资产发行和交易的成本并提供更多新玩法。UTXOSwap 将基于 UTXO 模型探索 Bitcoin Finance 独有的特点，致力于成为比特币生态的流动性基础设施，促进比特币生态的繁荣。
技术实现

在 UTXOSwap 上，用户进行 swap 交易时，主要包括以下三个步骤：
意图表达：用户通过签署一个包含交易资产类型、金额以及其他参数的消息，来表达他们的交易意图。聚合与匹配：聚合器收集所有用户的交易意图，搜索链上和链下的流动性资源，并进行意图匹配。交易提交：聚合器将所有符合条件的交易组装好，并提交至链上。
聚合器可以利用的流动性来源包括：
直接匹配的用户意图AMM cells（CKB 链上构建的各类 AMM 流动性池）第三方做市商提供的流动性

Intent Cell
Intent cell 用于记录用户的交易意图，并确保其在消费时满足特定条件。对于 AMM 操作，意图可以分为三种类型：Swap、AddLiquidity 和 RemoveLiquidity。
用户在使用 UTXOSwap 时，首先需要发起一笔 CKB 交易，并在 intent cell 中详细记录其交易意图。例如，用户设定滑点并选择特定的资金池进行交易时，这些参数将被写入 intent cell。当 intent cell 被解锁时，脚本会验证输出中返回给用户的资产是否满足滑点要求，并检查是否包含指定的资金池 cell。

Intent cell 支持多种交易形式，除了标准的 swap 交易外，还将支持 limit order 和 twap（时间加权平均价格）交易等。这使得 UTXOSwap 平台能够满足用户的复杂交易需求并增强策略灵活性。用户可以通过详细设定 intent cell 中的参数，精确控制交易执行的条件和时机，优化交易效率和结果。
比特币还有一个独特功能是支持 PSBT（部分签名的比特币交易），这允许多方通过部分签名参与构建同一个交易。在 CKB 中，相应的 PSBT 扩展功能是 Open Transaction。在 UTXOSwap 集成 Open Transaction 后，用户可以通过链下签名方式直接构建交易意图，其他人则可以通过补充输入和输出来满足这些意图，可以提供更优的交易体验。

AMM Cell
AMM cell 负责与 AMM 相关的全部验证逻辑，包括意图交易的验证，流动性池中资产的管理，以及流动性凭证的生成和销毁。
在交易执行过程中，AMM cell 会验证每一笔交易意图，确保用户需求得到满足。同时，它还会检查流动性池的状态变化是否严格按照预设的 AMM 曲线进行，以确保整个资金池的安全性。

产品优势

Intent-based 混合交易模型

在传统的 AMM 交易模式中，每次交易只有用户和流动性池两个交易角色参与，用户要交易就只能接受当前流动性池的报价。站在用户角度，这个模式虽然提升了交易的便利性，但是损失了获得更好的成交价格的可能性，用户只能在两者之间做出取舍；站在做市商角度，创建流动性池被动做市会带来无常损失并丧失定价能力，而主动成交又会有滑点、MEV 等带来的不确定性。
为了解决上面的问题，基于意图的（Intent-based）交易模型出现了。在这种模型里，用户不再被动接受价格，而是主动给出自己的交易意图，比如“用 10 个 A Token 换到至少 20 个 B Token”。流动性供给侧也发生了变化，AMM 流动性池只是流动性供给的一种选择，如果有利可图，做市商可以根据用户意图直接成交；即便没有做市商撮合，如果 AMM 流动性池的价格符合用户意图的区间，交易也可以顺利完成，这时的交易流程就变成了限价单模式。
UTXOSwap 利用 UTXO 编程模型中链上验证的特点，做到了链下撮合、链上成交，很好地实现了上述基于意图的混合交易模型。在未来，我们还会对用户表达意图的能力进行拓展，比如实现类似荷兰拍的逻辑：价格在一定区间内随时间下降，这个过程中做市商根据自己的成本互相竞争，最后可以由 AMM 进行保底成交。
支持自定义曲线和手续费率

在 UTXOSwap 的 AMM 模型中，交易对创建者可以根据资产的特点对定价曲线进行自定义，比如针对稳定币类型的交易对可以采用 curve 类型的曲线。此外，交易池还有一些可选的手续费率，能够让不同的 LP 自由选择，最大化收益。
超低 Gas Fee，可用任意代币支付
UTXOSwap 单笔交易的 gas fee 成本约为 1/10000 CKB，按照当前的 CKB 价格计算，不到 0.000002（百万分之二）美元，几乎可以忽略不计。此外，得益于 UTXO 链下计算的特点，用户的交易意图在链下就可以进行可行性验证，如果无法成交则不会上链，用户也就不需要支付手续费。
另一方面，得益于 UTXOSwap 的设计，无论是 gas fee 还是状态空间占用，所需 CKB 都不需要用户感知，用户可以用任意 token 来无感支付这些成本，UTXOSwap 会自动将用户支付的 token 进行转换，并帮助用户进行 gas fee 的支付或者新 cell 的创建。
兼容多链钱包，L1/L2 无感操作
UTXOSwap 的用户无需下载使用专门的 CKB 钱包，而是可以直接使用熟悉的 BTC 钱包完成 L1/L2 的 Leap，L2 的交易以及转账等操作。体验上，用户的 BTC 地址会对应一个固定的 CKB 地址，而且 CKB 地址的控制权只属于这个 BTC 地址。这个对应关系是链级别的，因此在其他兼容多链钱包的 CKB 应用里，同一个 BTC 地址对应的 CKB 地址也能保持统一。
除了 BTC 之外，技术上还能支持 ETH / Solana / Tron 等多条主流公链钱包直接使用，如果未来有相应的资产协作场景，例如 CKB 到 Solana 的跨链，我们也会同步进行对应钱包的支持。

4 月 18 日晚，CKB 生态基金将联合比特大陆、Matrix Labs、SafePal 在迪拜市中心共同举办首届「Bitcoin POW Night」。
对于那些已经参与了区块链或者对加密货币领域感兴趣的人，尤其是那些专注于工作量证明和挖矿生态的人来说，Bitcoin POW Night 不仅仅是一次聚会，更是一个与比特币生态系统中的顶级投资者、创新项目、交易所和 KOL 面对面交流的绝佳机会，是一场不容错过的盛会。
在迪拜喷泉秀的映衬下，本次活动将为您带来一段激动人心的社交互动之旅。赶快报名，让我们一起庆祝比特币充满活力的生态吧！
活动信息：
日期：2024 年 4 月 18 日（星期四）时间：18:30 - 22:00 GMT+4地点：Third Avenue Boutique (L1, Dubai Mall) 
本次活动名额有限，先到先得！我们期待与您共度一个难忘的夜晚，开启一段新的旅程。
活动议程：
18:30-19:30：签到19:30：迪拜喷泉秀19:35-20:00：主持人开场20:00：迪拜喷泉秀20:05-20:30：圆桌讨论20:30-22:00：自由交流环节与茶歇（每 30 分钟欣赏一次迪拜喷泉秀）

Co-host
CKB Eco Fund 
CKB Eco Fund （前身为 InNervation）致力于促进 CKB 领域的创新，投资早期和成长阶段的初创公司，这些公司推动了 CKB 的采用、可扩展性和可访问性。

比特大陆
比特大陆是全球领先的数字货币矿机厂商，自 2013 年创立以来，旗下品牌 ANTMINER 长期在业内保持技术和市场优势地位，客户覆盖全球 100 多个国家和地区。秉持着 “让人类数字世界更美好” 的核心愿景，比特大陆不仅与全球客户建立了基于 “共赢、长期、忠诚” 的商业合作关系，还通过其卓越的算力能效比技术，为全球区块链网络提供了一流的、安全稳定的算力基础设施和综合解决方案。
Matrix Labs
Matrix Labs 是一支由区块链爱好者组成的专业团队，致力于构建 Autonomous World 并推进区块链技术的应用。Matrix Labs 与加拿大 MITACS 和 University of Alberta 在 Web3 研究方面建立了重要合作伙伴关系，正在积极塑造去中心化技术的未来格局。
SafePal 
SafePal 成立于 2018 年，是一款全面的加密钱包套件，提供硬件钱包、移动应用程序和浏览器扩展钱包解决方案。作为一款非托管钱包套件，SafePal 旨在让用户能够在去中心化世界中安全地获取机会，从而让他们拥有自己的加密货币冒险之旅。