比特币限制条款:开启BTC新一代可编程性

比特币限制条款:实现可编程性的新方向

比特币社区最近对重新启用OP_CAT等操作码展开了热烈讨论。Taproot Wizard通过推出Quantum Cats NFT和声称获得BIP-420编号等方式,吸引了大量关注。支持者称,启用OP_CAT可以实现"限制条款",从而为比特币带来智能合约和可编程性。

"限制条款"(covenants)这个概念引发了开发人员多年的讨论。除了OP_CAT,还有OP_CTV、APO、OP_VAULT等多种实现限制条款的技术方案。那么,什么是比特币的"限制条款"?为什么能引发如此广泛和持久的关注?它能为比特币带来哪些可编程性?背后的设计原理是什么?本文将对这些问题进行概览性介绍和讨论。

详解Covenants:如何实现比特币的可编程性?

什么是"限制条款"

"限制条款"(covenants)是一种可以为未来的比特币交易设置条件的机制。当前的比特币脚本已经包含了一些限制条件,比如需要输入有效签名、提供符合要求的脚本等。但只要用户能解锁,就可以将UTXO花费到任意地方。

而限制条款在此基础上增加了更多限制,例如限制UTXO后续的花费去向,实现"专款专用"的效果;或者限制一笔交易中其他输入的条件等。

更准确地说,目前的比特币脚本也具备一定的限制条款功能,如基于操作码的时间锁。通过检查交易的nLock或nSequence字段,可以实现交易花费前的时间限制。但目前主要局限于时间方面的限制。

开发人员设计这些限制检查的目的,不仅仅是为了限制,更是为了设置交易执行的规则。用户只能按照预先设定的规则执行交易,从而完成预定的业务流程。

因此,限制条款反直觉地可以解锁更多应用场景。

详解Covenants:如何实现比特币的可编程性?

应用场景

确保Staking的惩罚

限制条款的一个直观例子是Babylon在Bitcoin staking中的slash交易。

Babylon的Bitcoin staking过程是用户将BTC资产发送到主链上的一个特殊脚本中,花费条件包括两种:

  1. 正常结束:经过一定时间后,用户用自己的签名即可解锁,完成unstake过程。

  2. 惩罚结束:如果用户在Babylon租借安全性的PoS链上有双签等作恶行为,那么通过EOTS(可提取一次性签名)可以解锁资产,由网络中的执行角色将部分资产强制发送到燃烧地址(slash)。

这里的"强制发送"意味着即使可以解锁UTXO,该资产也不能随意发送到其他地方,只能被燃烧。这确保了作恶用户无法抢先用已知签名将资产转回给自己,逃脱惩罚。

在OP_CTV等限制条款实现后,可以在staking脚本的"惩罚结束"分支中增加相关操作码来实现限制。

而在OP_CTV启用前,Babylon需要通过用户和委员会共同执行的变通方法来模拟实现限制条款的强制执行效果。

详解Covenants:如何实现比特币的可编程性?

拥堵控制

网络拥堵时,交易池中积累了大量待打包交易,用户需要提高手续费以获得快速确认。如果用户必须发送多笔交易给多个收款方,就不得不承担较高成本,同时进一步推高整个网络的手续费率。

有了限制条款后,发送方可以先承诺一笔批量发送交易。这个承诺让所有接收方相信最终交易都会执行,可以等到手续费率降低时再发送具体交易。

当对区块空间需求很高时,交易变得昂贵。使用OP_CHECKTEMPLATEVERIFY,大批量支付处理商可以将所有付款聚合到单个O(1)交易中确认。之后当区块空间需求减少时,可以从该UTXO中扩展出付款。

这是OP_CTV这个限制条款提出的典型应用案例之一。

详解Covenants:如何实现比特币的可编程性?

保管库

保管库(vault)是比特币应用中广泛讨论的场景,尤其在限制条款领域。日常操作需要在资金保管与使用需求间平衡,人们希望有一类保管金库应用:既能保证资金安全,即使账户被黑(私钥泄露)也能限制资金使用。

基于限制条款技术,可以较容易构建保管库类应用。

以OP_VAULT方案为例:花费保管库资金时,需要先发送一笔交易上链表明意图("trigger"),并设置条件:

  • 正常情况:第二笔交易是最终取款交易。等待N个区块后,可将资金进一步花费到任意地址。

  • 异常情况:如发现是被盗交易(或被胁迫),在N个区块的取款交易发送前,可立即将资金发送到更安全的地址。

需要注意,即使没有限制条款,也可以构建保管库应用。一种方法是用私钥准备好未来花费的签名,然后销毁私钥。但这种方式仍有局限,如需确保私钥已销毁、金额和手续费需提前确定等,缺乏灵活性。

详解Covenants:如何实现比特币的可编程性?

更健壮和灵活的状态通道

状态通道(包括闪电网络)在节点可观察最新状态、能正常发布最新状态上链的情况下,可以认为具有与主链近乎相同的安全性。而有了限制条款后,一些新的状态通道设计可以在闪电网络基础上更加健壮或灵活,比较知名的包括Eltoo、Ark等。

Eltoo(也称LN-Symmetry)是典型例子。它为闪电网络提出了一个执行层,允许任何后来的通道状态取代之前状态,无需惩罚机制,因此可以避免闪电网络节点必须保存多个之前状态以防对手作恶。Eltoo提出了SIGHASH_NOINPUT签名方式,即APO(BIP-118)来实现这一效果。

Ark旨在降低闪电网络的入站流动性和通道管理等难度。它是一种joinpool形式的协议,多个用户可在一定时间内接受一个服务提供商作为交易对手,在链外进行虚拟UTXO(vUTXO)交易,但在链上共享一个UTXO以降低成本。与保管库类似,Ark也可在当前比特币网络上实现;但引入限制条款后,Ark可基于交易模板降低所需交互量,实现更去信任化的单边退出。

详解Covenants:如何实现比特币的可编程性?

限制条款技术概览

从上述应用可以看出,限制条款更像一种效果而非某种具体技术,因此有多种实现方式。可以从以下几个维度进行分类:

  • 类型:通用型、专用型
  • 实现方式:基于操作码、基于签名
  • 递归性:递归、非递归

其中,递归是指一些限制条款的实现可以通过限制下一笔输出来限制再下一笔的输出,实现跨越多笔交易的限制。

主流的限制条款设计包括:

  • OP_CTV:通用型,基于操作码,非递归
  • APO:通用型,基于签名,非递归
  • OP_VAULT:专用型,基于操作码,非递归
  • OP_CAT:通用型,基于操作码,递归(如果与OP_CAT结合)

详解Covenants:如何实现比特币的可编程性?

限制条款的设计

目前的比特币脚本主要限制了解锁条件,没有限制UTXO如何进一步被花费。要实现限制条款,需要反思为什么当前脚本无法实现这一功能。

主要原因在于目前的比特币脚本无法读取交易自身的内容,即交易的"内省"(introspection)。

如果能实现交易内省——检查交易的任何内容(包括输出),就可以实现限制条款了。

因此限制条款的设计主要围绕如何实现内省展开。

详解Covenants:如何实现比特币的可编程性?

基于操作码 vs 基于签名

最直接的思路是增加一个或多个操作码(一个操作码+多种参数,或多个不同功能的操作码),直接读取交易内容。这就是基于操作码的思路。

另一种思路是不在脚本中直接读取和检查交易内容,而是利用交易内容的哈希——如果已对这个哈希进行签名,那么只要在脚本中改造如OP_CHECKSIG等来检查这个签名,就可以间接实现交易内省及限制条款。这是基于签名的设计方式,主要包括APO和OP_CSFS等。

详解Covenants:如何实现比特币的可编程性?

APO

SIGHASH_ANYPREVOUT(APO)是一种提议中的比特币签名方式。签名最简单的方式是对交易的输入输出都承诺,但比特币还有更灵活的方式,即SIGHASH,可选择性地对交易中的输入或输出进行承诺。

APO的SIGHASH只对输出签名,不对输入部分签名。这意味着用APO方式签名后的交易,可以之后附加到任何满足条件的UTXO上。

这种灵活性是APO实现限制条款的理论基础:

  • 可以预先创建一笔或多笔交易
  • 通过这些交易信息构建出一个只能求出一个签名的公钥
  • 这样任何发送到该公钥地址上的资产都只能通过预先创建的交易来花费

值得注意的是,因为这个公钥没有对应的私钥,所以可以确保这些资产只能通过预先创建的交易来花费。我们就可以在预先创建的这些交易中规定资产的去向,从而实现限制条款。

我们可以通过对比以太坊的智能合约来理解:通过智能合约我们可以实现的也是只有通过一定条件,才能从合约地址中取款,而非靠一个EOA签名就任意花费。从这点来看,比特币通过签名机制的改进就可以实现这种效果。

但上述过程中的问题在于计算时存在循环依赖,因为需要知道输入内容来预签并创建交易。

APO以及SIGHASH_NOINPUT实现这种签名方式的意义在于可以解决这种循环依赖问题,计算时只需要知道(指定)交易的全部输出即可。

详解Covenants:如何实现比特币的可编程性?

OP_CTV

OP_CHECKTEMPLATEVERIFY(CTV),即BIP-119,采用了改进操作码的

此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 赞赏
  • 评论
  • 分享
评论
0/400
暂无评论
交易,随时随地
qrCode
扫码下载 Gate APP
社群列表
简体中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)