比特币扩容方案深度解析：内省与契约的第三部分探讨

概述

比特币脚本在设计上相比以太坊等图灵完备区块链显得相当受限，仅支持基础操作，甚至连乘除法这样的基本运算都无法实现。更关键的是，比特币脚本几乎无法访问区块链自身的数据，这大大限制了其灵活性和可编程性。正因如此，让比特币脚本具备内省功能一直是开发者们努力的方向。

内省功能使得比特币脚本能够检查和约束交易数据，从而根据特定交易细节控制资金使用方式，实现更复杂的功能。目前大多数比特币操作码要么推送用户提供的数据到栈上，要么操作栈上已有数据。而内省操作码则可以将当前交易中的数据（如时间戳、金额、交易ID等）推送到栈上，为UTXO支出提供更精细的控制。

当前比特币脚本中仅有三类主要操作码支持内省：CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY，以及CHECKSIG及其变体CHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG和CHECKMULTISIGVERIFY。

契约本质上是对比特币转移方式的限制，允许用户指定UTXO的分配规则。许多契约都是通过内省操作码实现的，关于内省的讨论现在被归类为比特币Optech中的契约话题。

比特币目前有两个契约：CSV（CheckSequenceVerify）和CLTV（CheckLockTimeVerify），这两个基于时间的契约是许多扩容方案（如闪电网络）的基础。这表明比特币的扩容方案在很大程度上依赖于内省和契约功能。

在加密货币领域，我们通常通过承诺机制（通常使用哈希实现）来为比特币转移添加条件。为了验证转移要求是否满足，还需要签名机制进行验证。因此，契约中涉及大量对哈希和签名的调整。

下面我们将详细介绍几个备受关注的契约操作码提案。

CTV（检查模板验证）BIP-119

CTV（CheckTemplateVerify）是包含在BIP-119中的比特币升级提案，已在社区引发广泛讨论。该提案允许输出脚本指定支出交易的模板，包括nVersion、nLockTime、scriptSig哈希、输入计数、序列哈希、输出计数、输出哈希、输入索引等字段。这些模板限制通过哈希承诺实现，当资金被支出时，脚本会检查支出交易中指定字段的哈希值是否与输入脚本中的哈希值匹配，从而有效限制该UTXO未来交易的时间、方式和金额。

值得注意的是，输入交易ID（TXID）被排除在这个哈希之外。这种排除是必要的，因为在传统交易和隔离见证交易中使用默认的SIGHASH_ALL签名类型时，TXID取决于scriptPubKey中的值。包含TXID会导致哈希承诺中出现循环依赖，使其无法构造。

CTV通过直接提取指定交易信息进行哈希，并将其与栈上的承诺进行比较来实现内省。这种方法对链上空间要求较低，但灵活性较差。

比特币二层解决方案如闪电网络的基础是预签名交易。CTV实现了一种更严格的预签名形式，将预签名承诺发布到链上，并限制在预定义模板中。CTV最初旨在缓解比特币网络拥堵，也可称为拥堵控制。在高拥堵时期，CTV可以在单个交易中承诺多个未来交易，避免在高峰时段广播多个交易，待拥堵缓解后再完成实际交易。这在交易所遭遇挤兑时特别有用。此外，该模板还可用于实施保险库（Vaults）以防止黑客攻击，因为资金流向已预先确定，黑客无法使用CTV脚本将UTXO转移到自己的地址。

CTV能显著增强二层网络。例如在闪电网络中，CTV可以通过将单个UTXO扩展为CTV树，创建超时树（Timeout Trees）和频道工厂（Channel Factories），只需一个交易和一个确认即可打开多个状态通道。CTV还通过ATLC支持Ark协议中的原子交易。

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118引入了一种新的签名哈希标志类型SIGHASH_ANYPREVOUT，用于Taproot脚本（tapscript），旨在实现更灵活的支出逻辑。APO与CTV有许多相似之处。在处理scriptPubKeys和TXIDs之间的循环问题时，APO的方法是排除相关输入信息，仅签署输出，从而允许交易动态绑定到不同UTXO上。

从逻辑上看，签名验证操作OP_CHECKSIG（及其变体）执行三个功能：组装支出交易的各部分、对这些部分进行哈希、验证该哈希是否由给定密钥签名。签名的具体细节具有很大灵活性，决定哪些交易字段需要签名由SIGHASH标志决定。根据BIP 342中对签名操作码的定义，SIGHASH标志分为SIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE和SIGHASH_ANYONECANPAY。SIGHASH_ANYONECANPAY控制输入，其他标志控制输出。

SIGHASH_ALL是默认标志，签署所有输出；SIGHASH_NONE不签署任何输出；SIGHASH_SINGLE签署特定输出。SIGHASH_ANYONECANPAY可与前三个标志一起设置。如果设置了SIGHASH_ANYONECANPAY，则只签署指定输入；否则必须签署所有输入。

显然这些标志并不能消除输入的影响，即使是SIGHASH_ANYONECANPAY也需要承诺一个输入。因此BIP 118提出了SIGHASH_ANYPREVOUT。APO签名不需要承诺已支出的输入UTXO（称为PREVOUT），只需签署输出，从而提供更大的比特币控制灵活性。通过预先构建交易并创建相应的一次性签名和公钥，发送到该公钥地址的资产必须通过预构建的交易支出，实现契约功能。APO的灵活性还可用于交易修复；如果交易因费用过低而卡在链上，可以轻松创建另一笔交易增加费用，无需新签名。此外，对于多签名钱包，不依赖已支出的输入使操作更为便捷。

由于消除了scriptPubKeys和输入TXIDs之间的循环，APO可以通过在见证区块中添加输出数据实现内省，尽管这会增加见证区块的空间消耗。

对于闪电网络和保险库等链下协议，APO减少了保存中间状态的需求，大大降低了存储需求和复杂性。APO最直接的应用是Eltoo，它简化了通道工厂，构建了轻量且廉价的观察塔，并允许单方面退出而不留下错误状态，从而在多方面提升闪电网络性能。APO还可用来模拟CTV功能，但要求个人存储签名和预签名交易，比CTV更昂贵且效率较低。

APO的主要争议集中在需要新密钥版本的问题上，这无法通过简单向后兼容实现。此外，新签名哈希类型可能引入潜在的双重支付风险。经过广泛讨论，APO在原有签名机制基础上添加了常规签名以缓解安全问题，最终获得BIP-118代码。

OP_VAULT BIP-345

BIP-345提议新增两个操作码OP_VAULT和OP_VAULT_RECOVER，与CTV结合使用时可以实现一种特殊契约，允许用户对特定币种的支出施加延迟。在此期间，之前进行的交易可通过恢复路径”撤销”。

用户可通过创建特定Taproot地址来创建保险库（Vault），该地址必须在其MAST中包含至少两个脚本：一个带有OP_VAULT操作码用于预期提取过程，另一个带有OP_VAULT_RECOVER操作码确保在提取完成前任何时间都可恢复币种。

OP_VAULT如何实现可中断的时间锁定提取？它通过用指定脚本替换已支出的OP_VAULT脚本来完成这一点，有效更新MAST的单个叶子，同时保持其余Taproot叶子节点不变。这种设计类似于TLUV，但OP_VAULT不支持对内部密钥的更新。

通过在脚本更新过程中引入模板，可以限制支付。时间锁定参数由OP_VAULT指定，CTV操作码的模板限制了通过该脚本路径可以支出的输出集合。

BIP-345专为保险库（Vaults）设计，利用OP_VAULT和OP_VAULT_RECOVER提供安全保管方法，使用高度安全的密钥（如纸钱包或分布式多签名）作为恢复路径，同时为常规支付配置一定延迟。用户设备持续监控保险库支出，如果发生意外转账，用户可以启动恢复操作。

通过BIP-345实现保险库需考虑成本问题，特别是恢复交易成本。可能的解决方案包括CPFP（子交易支付父交易费用）、临时锚定和新的SIGHASH_GROUP签名哈希标志。

TLUV（TapleafUpdateVerify）

TLUV方案围绕Taproot构建，旨在有效解决从共享UTXO退出的问题。其指导原则是当Taproot输出被支出时，可通过加密转换和Taproot地址内部结构对内部密钥和MAST（tapscript trie）进行部分更新。这使得契约功能的实现成为可能。

TLUV方案概念是通过引入新操作码TAPLEAF_UPDATE_VERIFY，基于当前支出输入创建新Taproot地址。这可通过执行以下一个或多个操作实现：更新内部公钥、修剪Merkle路径、移除当前执行脚本、在Merkle路径末尾添加新步骤。

具体而言，TLUV接受三个输入：指定如何更新内部公钥；指定Merkle路径的新步骤；指定是否移除当前脚本和/或修剪Merkle路径的多少步。TLUV操作码计算更新后的scriptPubKey，并验证与当前输入对应的输出是否支出到此scriptPubKey。

TLUV灵感来源于CoinPool概念。目前共同池可通过预签名交易创建，但若要实现未经许可的退出，则需要创建指数级增长数量的签名。而TLUV允许无需任何预签名即可实现未经许可的退出。例如，一组合伙人可使用Taproot创建共享UTXO，将资金汇集在一起。他们可使用Taproot密钥内部移动资金或联合签署以发起外部支付。个人可随时退出共享资金池，移除其支付路径，而其他人仍可通过原始路径完成支付，且个人退出不会暴露关于其他人的额外信息。这种模式相比非池化交易更加高效和私密。

TLUV操作码通过更新原始Taproot Trie实现部分支出限制，但未实现对输出金额的内省。因此还需要新操作码IN_OUT_AMOUNT。该操作码将两项推送到栈上：此输入的UTXO金额和对应输出的金额，然后使用TLUV的人应通过数学运算符验证在更新后的scriptPubKey中资金是否得到适当保留。

输出金额的内省增加了复杂性，因为金额以satoshi表示需要最多51位，而脚本仅允许32位数学操作。这需要重新定义操作码行为以升级脚本中的运算符，或使用SIGHASH_GROUP替代IN_OUT_AMOUNT。

TLUV在去中心化Layer 2资金池方面具有潜力，尽管在调整Taproot Trie方面的可靠性仍需确认。

MATT

MATT（Merkleize All The Things）旨在实现三个目标：Merkle化状态、Merkle化脚本和Merkle化执行，从而启用通用智能合约。

Merkle化状态涉及构建Merkle Trie，每个叶子节点表示状态的哈希值，Merkle根表示合约整体状态。Merkle化脚本指使用Tapscript形成MAST，每个叶子节点表示可能的状态转换路径。Merkle化执行通过加密承诺和欺诈挑战机制实现。对于任何计算函数，参与者可离线计算，然后发布承诺f(x)=y。如果其他参与者发现错误结果f(x)=z，可发起挑战。仲裁通过二分查找进行，类似于Optimistic Rollup原理。

要实现MATT，比特币脚本语言需要具备以下功能：强制输出具有特定脚本（及其金额）；将一段数据附加到输出；从当前输入（或其他输入）读取数据。第二点至关重要：动态数据意味着状态可通过支出者提供的输入数据计算，实现状态机模拟，确定下一个状态和附加数据。MATT方案通过OP_CHECKCONTRACTVERIFY（OP_CCV）操作码实现这一点，该操作码是之前提议的OP_CHECKOUTPUTCONTRACTVERIFY和OP_CHECKINPUTCONTRACTVERIFY操作码的合并，使用附加标志参数指定操作目标。

控制输出金额的最直接方法是直接内省；然而输出金额是64位数字，需要64位算术，这在比特币脚本中相当复杂。OP_CCV采用类似OP_VAULT的延迟检查方法，所有指向具有CCV的相同输出的输入金额被累加，作为该输出金额下限。延迟的原因是这项检查发生在交易处理过程中，而非输入的脚本评估期间。

考虑到欺诈证明的普遍性，某些MATT合约变体应能实现所有类型智能合约或Layer 2构造，尽管需要准确评估额外要求（如资本锁定和挑战期延迟）；进一步研究需要评估哪些应用适用于交易。例如，使用加密承诺和欺诈挑战机制模拟OP_ZK_VERIFY功能，实现比特币上的无信任Rollups。

实践中已有进展。Johan Torås Halseth使用MATT软件分叉提案中的OP_CHECKCONTRACTVERIFY操作码实现了elftrace，允许任何支持RISC-V编译的程序在比特币区块链上验证，使合约协议中的一方可通过合约验证访问资金，实现比特币原生验证的桥接。

CSFS（OP_CHECKSIGFROMSTACK）

从APO操作码引入中我们了解到OP_CHECKSIG（及其相关操作）负责组装交易、进行哈希计算和验证签名。但这些操作验证的消息是通过操作码对交易序列化得出的，不允许指定其他消息。简单来说，OP_CHECKSIG（及其相关操作）通过签名机制验证作为交易输入的UTXO是否已被签名者授权支出，保护比特币安全性。

CSFS即”从栈中检查签名”。该操作码从栈中接收三个参数：签名、消息和公钥，然后验证签名有效性。这意味着用户可通过Witness将任何消息传递到栈中，并通过CSFS验证，在比特币上实现一些创新。

CSFS灵活性使其能实现支付签名、授权委托、预言机合约、双重支付保护担保等机制，更重要的是还能实现交易内省。使用CSFS进行交易内省的原理相当简单：如果通过Witness将OP_CHECKSIG使用的交易内容推送到栈中，并使用相同公钥和签名通过OP_CSFS和OP_CHECKSIG验证，且两者都成功，那么传递给OP_CSFS的任意消息内容就与OP_CHECKSIG隐式使用的序列化支出交易（及其他数据）相同。我们从栈中获得已验证的交易数据，这些数据可用于通过其他操作码对支出交易施加限制。

CSFS通常与OP_CAT一起出现，因为OP_CAT可连接交易的不同字段以完成序列化，允许更精确地选择需要进行内省的交易字段。若无OP_CAT，脚本不能从可单独检查的数据中重新计算哈希值，因此真正能做的只是检查哈希是否对应于特定值，意味着这些币只能通过特定交易支出。

CSFS可实现像CLTV、CSV、CTV、APO等操作码，使其成为多功能内省操作码。因此也有助于比特币Layer2扩展解决方案。缺点是需要在栈上添加已签名交易的完整副本，可能显著增加使用CSFS进行内省的交易大小。相比之下，像CLTV和CSV这样的单用途内省操作码开销较小，但每添加一个新的特殊内省操作码都需要共识变更。

TXHASH (OP_TXHASH)

OP_TXHASH是一种简单的内省操作码，使操作员能够选择并将特定字段的哈希值推送到栈上。具体来说，OP_TXHASH从栈中弹出一个txhash标志，并根据该标志计算一个（标记的）txhash，然后将结果哈希值推送回栈中。

由于TXHASH和CTV之间的相似性，社区内对这两者进行了大量讨论。TXHASH可被视为CTV的通用升级，提供更高级的交易模板，允许用户显式指定支出交易的各个部分，从而解决与交易费用相关的许多问题。与其他Covenant操作码不同，TXHASH不需要在Witness中复制必要的数据，进一步减少存储需求；与CTV不同，TXHASH不兼容NOP，只能在tapscript中实现；TXHASH和CSFS的组合可作为CTV和APO的替代方案。

从构建Covenant的角度看，TXHASH更有利于创建”加法Covenant”，在这种情况下，你希望固定的所有交易