以比特币应用编程为起点，探讨如何解决 CKB 的编程特性

以下内容转载自 Nervos Talk 论坛，作者 Ajian（比特币内容平台 BTC Study 主编）。

摘要

理解一个系统的可编程性要求我们在这个系统中构建基于分布式应用编程的探索，为我们理解CKB单元的基本构建框架。不仅如此，它还将CKB的编程知识分解为目标对象，并在那里获得了关于每个部分的可编程性增益。

一.引言

“可编程性”是人们在比较区块链系统时经常采取的一个维度。然而，关于可编程性的描述方法，却常见分歧。一种常见的表现是，“XX区块链支持图灵完备的”，或者，“XX区块链支持通用的编程”，意思是表示这里的“XX区块链”具备强大的可编程性。这些语句暗示了一些道理：支持图灵完备编程的系统一般都比常规的编程更容易。但是，智能合约系统的结构特征有多个方面，这一语句只涉及其中一方面，因此，不足以对它进行足够深的理解：开发人员从中得不到指引，普通用户无法实现此分辨力欺诈。

智能合约系统在结构上的特征包括：

• 状态表达（合约）的基本形式（账户 vs. 交易输出）
• 是否允许编程任意计算（“图灵完备”这个词所涉及的就是这个方面）
• 执行过程可创造新数据，还是只传出布尔值？（计算 vs. 验证）
• 是否允许在合约内记录额外的状态
• 一个合约在执行的时候股权激励另一个合约

因此，在“可否编程任意计算”之外，至少还有四个方面的特征威胁一个智能合约系统的可编程性。甚至可以说，这些其它方面的特征是更为重要的，一致性更深层地决定了什么容易实现、什么难以实现；什么是较为经济的实现，而什么是较为低效的实现。

举个例子，人们常常拿以太坊作为良好可编程性的例子，但是，以太坊的优缺点在于它的基本形式是账户抽象（例如，支付通道、一对一的打赌合约） —— 并非绝对不能实现，只是吃力不讨好。以太坊社区从未有过尝试实现支付通道/状态通道的工程，理论选项也有很多，但时至今日这些项目似乎都没有活跃过 —— 这显然不能归咎于开发者不努力。如今在以太坊上活跃的工程都采用了 “资金矿池” 的形式，而非 “点对点合约” 的形式，并不是偶然。同样地，当前人们也许对以太坊的可编程性很满意，但是，若要实现 “账户抽象（account abstract）” 的泛化，账户模型却可以说是先天不足。

我们已经知道的是，CKB允许编程任意的计算、允许在合约记录额外的状态、也允许一个合约在执行时访问另一个合约的状态。但是，其合约的形式是交易的输出（称为“Cell”），并且它和以太坊智能合约系统以及其中的合约实例有关，以及如何获取CKB如何实现这些结构特性，以及如何认识CKB的可编程性。

通过使用物联网，我们能够更好地利用和集成智能平台，提高系统的性能，同时还能够为用户提供更好的服务，例如：

二. CKB 与 BTC：多了什么？

基本结构

表达形式，的UTXO（“未支出的模块”），以及字段：

• 数量，以聪（Satoshi）为单位，表示该UTXO具备的比特币价值；
• 脚本公钥，也称锁定脚本，表示支出这笔资金所需满足的条件，也即为解锁这笔资金设定条件的智能合约程序。

与智能合约系统相关的项目，以及项目脚本的制定者是相当标准的：

• 它不允许编程任意计算；可用来验证的则较为实用的计算只有几种（签名检查、哈希原像检查、时间检查）
• 它不允许在合约内记录任何状态；（例如，你无法用脚本来限制单次支出的比例/额度；它在其中隐藏一种代币）
• 我们现在不允许在运行时访问另一个合约的状态（每个脚本都是发行版的，互不依赖）。

这种脚本虽然有限，但并不缺乏编写普通应用程序的能力，而且也恰好是我们探索 CKB 可编程性的基础。

与之相对的，CKB 的状态单元称为“Cell”，有四个字段：

• Capacity，类似于UTXO的数量，表达的是该Cell可以活动的空间大小，以字节（Bytes）为单位；
• Lock Script，类似于UTXO的脚本公钥，定义该Cell的所有权；只有它们自己数据能够通过Lock Script，才能“更新”这个Cell（也可以说释放这个Cell并用这些容量来铸造新的Cell）；
• 数据，数据，任意数据，其容量限制；
• Type Script，可选的脚本，用于为 Data 的更新设定条件。

此外，Lock Script 和 Type Script还可以实现任意计算。你可以提供任意的签名验证算法，也可以提供任意一种哈希算法的原像检查，等等等等。

读者很容易就能明白，Cell相比UTXO在可编程性上的提升：

• Cell可以编程任意计算，而不是只能编程每一个计算；它的专有验证会更加灵活；
• 因为 Data 和 Type Script 字段，Cell 可以记录额外的状态；事实上允许 Cell 承载所谓的“UDT（用户自定义的代币”）。

: Cell 本身的“交易输出”结构，宝宝点本身能带来好处非常非常巨大的，但是，仅从描述上来说，我们尚不知晓 Cell 是如何实现“一个合约在运行时另一个合约的好”的。为此，我们需要借助社区建立了一个宽度的概念：“限制条款（covenants）。”

法律条款

限制条款的本意是限制商品能被花到哪里去。在当前的比特币（发布任何限制条款提议）上，商品资金一旦解锁，就可以花到第三方（可以支付给任意的脚本公钥）。但限制条款是，可以用某种方式，限制它只能花到某些地方去，比如，某一个 UTXO 将只能被某一笔交易花费，甚至有人能够为这个 UTXO 提供签名，它可以花到哪个地方也已经被这笔交易决定了。这种功能看起来有点奇怪，但能产生一些有趣的应用，随后会有专门的一节介绍。重要的是，它是我们进一步了解 CKB 可编程性关键

Rusty Russell正确地指出，限制条款可以理解为对交易的“内省”能力，即，当一个UTXO A被一笔交易B花费时，脚本运算程序可以读取交易B的部分（或者全部），然后检查它们是否与脚本预先要求的参数一致。例如，交易A的第一个输出的脚本公钥，是否与UTXO A的脚本公钥所要求的一致（这就是限制条款的最初含义）。

他的敏锐意识到，如果提供了完全的省能力，那么一个交易的输入就可以读取同一个交易的另一个输入状态，这就实现了我们前面说的“一个合约在运行时另一个合约状态”的能力。事实上，CKB Cell正是这么设计。

基于此，我们又可以将这种完全内省能力分成调查情况：

• 锁定脚本 读取其它（输入和输出）的锁定脚本
• Lock Script 读取其它（输入和输出）的 Type Script（以及 Data）
• Type Script 读取其它（输入和输出）的 Lock Script
• Type Script 读取其它（输入和输出）的 Type Script（以及 Data）

我允许我们在目标假设（Lock Script 和 Type Script 的功能分工）之下分析每一部分内省能力在其应用场景中的作用，也即分析每一部分为我们高效的可编程性增益。

在下面章节中，我们将讨论条款，并提出建议以达到更好的效果。

三.智能编程

公告显示，公司将使用“闪电通道/闪电网络”和“端点日志合约（DLC）”作为基于比特币脚本应用编程的案例。在展开之前，我们要先了解两个概念。

OP_IF 以及“承诺交易”

第一个概念是比特币脚本的流程控制操作码，比如：OP_IF、OP_ELSE。这些操作码跟计算机程序设计中的IF没有什么区别，它的作用就是根据不同的输入执行不同的语句。在比特币脚本的语境下，这意味着我们可以设置资金的多个解锁路径；搭配时间锁特性，这意味着我们可以分配行动的优先权。

以著名的“哈希时间锁合约（HTLC）”为例，这个脚本翻译成大白话就是：

或者，Bob可以揭晓某个哈希值H原像，再给出自己的签名，即可花费这笔资金；

或者，Alice可以在一段时间内，凭借自己的签名花费这笔资金。

这种“要么 …… 要么 ……”的效果，就是通过流程控制操作码实现的。

例如，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开设通道就可以实现免信任的多跳支付。 这就是闪电网络：

爱丽丝 — HTLC –> 鲍勃 — HTLC –> 卡罗尔 — HTLC –> 丹尼尔

Alice <– 原像 — Bob <– 原像 — Carol <– 原像 — Daniel

当Alice找到了这样的路径并希望给Daniel支付时，她向Daniel请求一个哈希值，据以构造一个HTLC 给Bob，并提示Bob给Carol转发一条消息相同的HTLC；消息中又提示Carol给Daniel转发消息相同的HTLC。当消息传到Daniel手上时，他向Carol揭示原像，从而获得HTLC的价值、更新合约状态；Carol也如法炮制，获得Bob的支付并更新通道状态；最后，Bob向Alice揭示原像、更新状态。由于HTLC的特性，这一连串的支付要么一起成功，要么一起失败，因此，它是免信任的。

闪电网络是由一条通道组成的，每条通道（合约）都是相互兼容的。这意味着爱丽丝（Alice）只需告诉鲍勃一条通道的地址，就可以与另一个通道建立相互兼容的协议。这意味着，在闪电网络的网络中，其他通道发生了相互兼容的事情，而不必理会其他通道中发生的相互兼容的事情，也不必理会这些相互兼容的事情使用了某种货币，甚至不必理会他们并不是利用了通道。

闪电网络的可扩展性不仅体现在闪电通道内部的支付速度于双方的硬件资源投入，还在于，由于国家的去中心化存储，单体数据库可以用最低的成本撬动最大限度的资金。

后续日志合约

方向日志合约（DLC）使用了一种叫做“适配器签名（adaptor signature）”的密码学技巧，使得比特币脚本可以编程出依赖于外部事件的金融合约。

适配器签名请访问一个签名仅限于加入一个私钥之后，才会变成有用的签名。以 Schnorr 签名为例，Schnorr 签名的标准形式是(R, s)，其中：

R = rG # 签名所用随机值 r 乘以椭圆曲线生成点，也可以说是 r 的公钥

s = r + Hash(R || m || P) * p # p 即为签名私钥，P 为公钥

验证签名即验证 sG = rG + Hash(R || m || P) * pG = 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。

我确实有三种可能的结果（因此卡罗尔的签名有三种可能）：

• 绿魔胜出，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 规划了未来的支出方式，因此 Funcoal 保证我们免信任地退出这个资金矿池，不需要任何人的帮助；又因为这个资金矿池只表现为一个 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 先承诺了一个操作码，以允许使用者通过新的一笔交易为该操作码传入的参数，从而更新整个脚本树叶子；这已经不是“根据指定条件验证传入的数据”了，而是“根据传入的数据产生新的有意义的数据”了，虽然函数启用的计算是比较有限的。

完整的 OP_VAULT 也利用了一些交易矿池策略（mempool policy）上的提供（比如 v3 格式的交易矿池）以取得更好的效果。这提醒了我们 “编程” 的历史可以比我们想象的更为广泛。（一个相似的例子是 Nervos Network 里面的 Open Transaction。）

五.理解CKB

在上述两个章节中，我们介绍了一种进一步的原型架构（比特币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钱包、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 是一等公民）。

举个例子：金沙注册开户送188金宝搏安卓版下载个卖点：金沙注册开户送188金宝搏安卓版下载协议。这种协议工具是一种承诺交易，其输入值是小于输出值的（因此它还不算是一笔有效的交易），但是，一旦能够为这笔交易提供足够的输入，它就是一笔有效的交易：一旦贷款人能够还款，放贷者就不能将质押的NFT据为有。这个承诺交易的免信任性基于交易的输入和输出的数额的检查，所以贷款人只能使用比特币来还款——即使贷款和放贷者都愿意接受另一种货币（比如以RGB协议发行的USDT），比特币交易也无法保证只要贷款人还了足够的USDT就能拿回自己的NFT，因为比特币交易根本不知道USDT的好（修订：换言之，无法以USDT还款为条件承诺交易。）

如果我们能够根据UDT定义发起检查，将可以让放贷者签名另一笔承诺交易，允许贷款人使用USDT来还款。交易将检查输入的USDT数量和输出的USDT数量，从而为用户使用USDT还款金额免信任性。

修订：假定这里用作质押的 NFT 和用于还款的代币 是使用同一套协议（比如 RGB）发行的，那么这里存在的问题是能够解决的，我们可以根据 RGB 协议一种承诺交易，使得 NFT 的转换和还款可以同步发生（在 RGB 协议内交易两个状态转换）。

接下来我们再省能力。

锁定脚本 读取其它锁定脚本

该国限制条款提议实施之后，比特币UTXO上的全部编程功能。包括上面提到的保险柜合约，以及基于OP_CTV的应用（例如拥堵控制）。

XueJie 曾经提过一个示例：让我们 CKB 上实现一种收款账户 Cell，使用这种 Cell 作为交易的输入时，如果输出的 Cell （使用相同 Lock Script 的 Cell）具备一些 Capacity，那么这个输入无需提供签名也能节省交易的成本。实际上，如果没有省的能力，这种 Cell 是无法实现的。这种收款账户 Cell 非常适合作为机构的收款方式，因为它可以将资金归集起来，缺点是它的隐私性不佳。

锁定脚本 读取其他类型脚本（以及数据）

这种能力的一个有趣的应用是股权代币。Lock Script 将根据其它输入中的代币 数量来决定能否动用自身的Capacity，以及这些Capacity能够花到哪里去（需要内省Lock Script的能力）。

类型脚本 读取其它 锁脚本

不确定，但可以假设有用。例如，可以在 Type Script 中检查交易的输入和输出的 Lock Scripts 保持不变。

Type Script 读取其他 Type Scripts（以及 Data）

集齐 n 个 token 可以换取更大的一个 token : )

六.结论

与实施出现的可编程任意计算的智能合约系统（如以太坊）相比，Nervos Network 采取了不同的结构；因此，对以往那些智能合约系统的了解，往往难以理解 Nervos Network 的基础。本文从一种比 CKB Cell 更为明确的架构——BTC UTXO——应用编程出发，提出了一种理解 CKB Cell 可编程性的方法。并且，运用“内省”的概念来理解 Cell 的“跨合约访问”的能力，我们可以划分运用内省能力的情形，解答它们确定具体的用途。

修改：

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

2. 不考虑 Cell 的交叉访问能力（即内省能力），锁脚本和类型脚本的区分可以认为是一种安全性升级：它划分了 UDT 的资产定义与保护方法；此外，可暴露状态的类型脚本（以及 Data）实现了 UDT 是一等公民的效果。

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

3. 考虑Cell的内省能力，Cell比post-covenants BTC UTXO更强的编程能力，并实现一些BTC + RGB难以实现的东西（因为BTC无法读取RGB的优点）

关于这些用途，本文无法提出很多具体的例子，但是这是因为金币使用者对CKB的生态缺乏的缘故。假以时日，相信人们在其中投入的越来越多的想象力，组合如今难以想象的应用程序。

致谢

感谢 Retric，Jan Xie 和 Xu 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