解释CTV， BIP119
翻译：DeepL，Google Translate 校对： 李林
CheckTemplateVerify (CTV)是一个提议中的比特币软分叉提案。它的目的是通过增加一个基本类型的 “契约 “或智能合约，为网络实现新的用例，这比目前比特币脚本能实现的要多。
为什么需要契约？
比特币，就目前而言，在交易的基础层面上，它的可编程性并不具备很大的灵活性–当然也不像它在用于签署交易的公钥和私钥层面上那样灵活。
目前，程序员可以用比特币脚本控制交易的输入，限制在交易花费前可以做什么，但他们不能控制允许签署什么类型的交易。换句话说，在今天大多数比特币智能合约中，用户可以通过定义必要的限制条件来控制一个币的解锁方式。但他们不能很好地控制一旦该币被解锁后可以做什么。
例如，人们可以用timelock定义一个交易可以花费的一定时间，有效地锁定了该交易，直到达到指定的块高度。在这种情况下，对资金的使用时间进行了限制，防止正确的钥匙解锁这些资金并使用它们。然而，在时间过后，在比特币区块链上达到区块高度时，钥匙可以解锁这些资金并自由使用。何时被限制，但不是什么或如何被限制。
因此，契约有能力为比特币的编程方式释放一系列新的可能性，通过预先定义哪些输出是可接受的，而不仅仅是控制输入。虽然复杂的契约有无限的可能性，可能会给网络带来安全风险，因为可能会产生意想不到的或意外的后果，但CTV的方案在大多数情况下是简单的。
什么是CTV？
简而言之，CTV允许比特币用户限制他们花费比特币的方式，即使他们拥有想要花费的比特币的密钥。
更重要的是，CTV允许这些支出限制以非交互方式执行。由CTV实现的一些用例今天可以实现，但大多数时候，参与智能合约安排的一组用户需要在线并手动互动以协调支出规则，这并不总是可能的。CTV使这些限制能够以编程方式执行，而不需要参与者的手动互动，因此提高了契约的可靠性。
今天，你可以随心所欲地花费你的UTXO。在一个后CTV世界中，你可以对你的UTXO制定规则，以控制或限制你花这些币的可能方式。不是什么时候花，而是如何花。通过将这些类型的新功能引入比特币，可以启用一个更多样化的使用案例集，出现一个新的应用生态系统。
CTV可以为比特币带来的一些功能包括加强安全、隐私和可扩展性。随着CTV的激活，用户将能够创建更复杂的托管解决方案，如金库，可以让比特币用户预先定义比特币从冷库到热库的预定和有限的支出，从而限制潜在黑客的破坏。CTV还可以带来支付池，这是一种安排，一群人可以共享一个UTXO，并在他们之间无信任地重新平衡资金，不仅增加了他们的隐私，还使比特币有更好的扩展机会。此外，CTV可以通过改进通道创建和赎回，以及哈希时间锁定合约(HTLCs)为闪电网络增压，从而提高比特币第二层协议的效率和流动性。
CTV是如何工作的？
在引擎盖下，CTV为比特币带来了一个新的opcode，这是对Bitcoin Script中可用操作集的新补充。
BIP119通过OP_NOP4向比特币添加了新的操作码OP_CHECKTEMPLATEVERIFY，通过软分叉实现协议的共识变化。
目前，编号的OP_NOP（OP_NOP1和OP_NOP4到OP_NOP10）在使用时被忽略，同时不会使交易无效；更值得注意的是，它们是预留操作码，可以利用它们来为协议添加新的操作码。然而，这对OP_NOP本身并不成立（没有数字），因为它是一个 “非操作 “操作码。
BIP119试图以OP_CHECKTEMPLATEVERIFY取代OP_NOP4，来承担验证作用。这个流程也被用于为协议增加OP_CHECKLOCKTIMEVERIFY和OP_CHECKSEQUENCEVERIFY，分别取代OP_NOP2和OP_NOP3。
OP_CHECKTEMPLATEVERIFY在运行时做三个检查。首先，自然是检查堆栈中是否有至少一个元素。如果有，它就会检查这个元素是否正好有32个字节–SHA-256哈希值的大小。如果堆栈上有一个项目，并且它有32个字节，那么CTV将检查它是否与当前输入索引处的事务的哈希值相匹配。
这一步–检查元素是否与哈希值匹配–正是执行的地方。在这里，程序正在验证传递给它的交易是否是合同（或契约）先前指定的 “可能的 “交易集的一部分–那些将获得批准的交易。这组交易将由用户在合同中事先定义。
尽管对于建立可以用CTV执行的合约来说不是必须的，Sapio还是一种专门为此目的设计开发中的编程语言。它抽象了低级别的编程细节，以方便建立比特币的智能合约，例如，组件–可重复使用的代码片断，以提高程序的可读性和可用性。
程序员首先用Sapio建立一个模板，指定一些条件，然后输出一个部分签名的比特币交易（PSBT）的列表，可以利用它来定义一个详尽的交易支出集–允许我们将交易中允许的输出集限制在一个小于所有可能输出集的集合。
CHECKTEMPLATEVERIFY通过约束大部分的数据，提前决定了所有可能的交易ID（TXID），从而对一个交易进行预承诺。这意味着，给定一个特定的UTXO和一个合同，你通常可以预先计算出所有的TXIDs。虽然是限制性的，但假设通过提前知道TXIDs，契约更容易被执行，因为要检查的交易范围受到了限制。
被操作码DefaultCheckTemplateVerifyHash分析的具体散列函数以串行方式散列交易的部分，从版本和锁定时间开始。接下来，如果交易不是SegWit交易，该函数会散列scriptSig散列，然后散列输入的数量、序列的散列和输出的数量。最后，该函数对输出的哈希值和输入索引进行哈希。
通过事先承诺（或确定）其中的大部分，不仅可以事先确定TXID，而且还可以在以后只设置其中的少数几个（可塑性强），并使验证更加有效，因为大量的字段已经被哈希化了。
BIP119的作者Jeremy Rubin告诉比特币杂志：“以特定方式排列字段的想法是，如果在未来的某个时间点，你在比特币中有OP_CAT这样的东西，你可能会在堆栈中操作这些字段，"。“按照你可能以编程方式改变它们的可能性的顺序，对它们有一些好处。”
“因此，部分想法是，nVersion是最不可能被改变的，输入索引是最可能被改变的，而其他一切都属于这个顺序的中间部分，“Rubin补充说。
我们的假设是，比特币开发者在编程时更有可能以编程的方式改变关于输出的信息，而不是输入的信息，因为一个契约试图限制一个币如何被花费。
因此，OP_CHECKTEMPLATEVERIFY所做的是检查该交易是否被允许。换句话说，它执行了用Sapio编程的契约所规定的限制。
但这种检查只发生在堆栈上的元素大小为32字节的情况下。如果不是，CTV将OP_NOP堆栈上的元素，这意味着它将不会执行失败，而是 “什么都不做”。
这种微妙的差别是为了适应未来在CTV之后的发展，例如，“CTV第二版 “在其中增加了一个标志字节–使该元素成为33字节。然后，由于CTV只检查32字节的元素，而不是用CTV来检查，该元素将被检查33字节的 “CTV第二版 “检查。而这是可能的，因为OP_NOP使脚本的评估得以继续。如果它失败了，评估就不会继续，因此这个元素就不会被 “CTV版本2 “检查。
“根据标准规则，带有33字节CTV的交易在这些变化下仍会被网络拒绝，但如果矿工将其放入区块中，则会有效，“Rubin解释说。“这确保了人们对它在未来被赋予特定含义的期望，阻止了不小心的使用。”
CTV将成为比特币的下一次升级？
比特币的升级过程以其有条不紊和谨慎的方式而闻名，这是网络生存的重要特征，也是确保每一个新加入的代码的正确性。因此，CTV是否可能很快被添加到比特币中，目前还很不清楚。
虽然不是一个新的建议–BIP是在2020年1月创建的–但著名的比特币开发者认为，需要围绕建议的变化进行更广泛的测试和讨论，特别是当它涉及到可能的优化和对替代方案的更详细考虑。
在撰写本文时，CTV将为比特币增加一套有限的新的可能性，因为它寻求在协议中实施一种低风险的契约形式。鲁宾告诉《比特币杂志》，我们的目标是为比特币提供新的功能，同时 “就对比特币验证的影响而言，很可能是我们做过的最简单的软分叉之一。”
“例如CLTV或CSV等升级，既需要一个软分叉来添加操作码，也需要一个软分叉来共识强化nLockTime和nSequence字段（上下文数据），而CTV的有效性只检查交易固有的属性，“Rubin补充说。
鲁宾还说，他觉得开发者社区在审查他的提案时，“有一点儿双重标准”。
“他对《比特币杂志》说：“CTV被要求达到的标准比我们以前做的任何事情都要高得多。“虽然我们应该一直寻求提高标准，“鲁宾澄清说，“但不应该不承认CTV已经达到或超过了以前分叉的测试和应用水平。”
本月早些时候，Spiral的比特币和闪电网络开发人员Matthew Corallo在推特说，“在比特币的历史上，没有任何时候可以提出把东西弄进共识……而不考虑替代方案。” Corallo声称，Rubin，以及那些从事和支持CTV的人，在过去的几年里，没有显示出 “一个更正式的方法，将其与替代方案进行比较”。
“强推CTV的感觉……几乎在所有方面都是错误的，“科拉罗补充。“与其说是合作工程，不如说是’我造了这个，我们来做吧'，而忽略了任何反馈。”
Blockstream的研究总监Andrew Poelstra也有进一步实验和分析的愿望。当被问及CTV是否是比特币目前扩展功能以支持契约的最好机会时，他告诉《比特币杂志》，他 “建议不是”，并补充说，“CTV并不是在比特币中实现契约的唯一建议方式–它在安全性和通用性之间做了权衡，在任何一个方向都有空间。”
“这可能的一种方式是，CTV可能是实现’减法契约’的最有效方式，即用户限制大部分交易数据，而只留下一小部分自由，“Poelstra说。“同时，其他建议，如自省操作码可能最适合’加法契约'，即大部分交易数据是自由的，只有少量的数据被限制。如果这是真的，而且社区需要更多的时间来探索，那么我们实际上会想要APO和CTV以及通用契约。”
APO，即SIGHASH_ANYPREVOUT，是另一个为比特币添加新功能的建议，在BIP118中指定。它的作者Christian Decker是Blockstream的研究员，专注于比特币的扩展解决方案，他告诉比特币杂志，他也认为APO和CTV是对比特币的 “补充而不是竞争 “的补充。
“两者都是有益的，“德克尔说。“因此，我同意我们应该在两者都准备好了，经过审查和测试后一起启动它们。”
目前，在比特币社区，激活的准备工作是一个微妙的话题。事实上，一些开发者对CTV的反对是基于CTV支持者所描绘的所谓紧迫感。如果没有准备好的变化最终被添加到比特币的代码中，急于部署可能是有害的。
Decker告诉《比特币杂志》，他理解CTV支持者希望尽快激活的想法，但是他完全能接受需要更长的时间才将他的提案加入比特币协议，即使这意味着采用更鲁棒的测试过程。
“我们认为强推一项变革是没有好处的，而且APO需要紧急部署，“德克尔说。“提案可以酝酿的时间越长，越多的人可以审查它并强调潜在的弱点。评审和开发人员的时间是比特币最稀有的资源，所以我们要尊重这一点，除了有一些[概念验证]的实施，例如eltoo。”
2021年12月，为了吸引更多的人关注他的提议，Rubin为CTV及其指定的BIP设立了一个BUG赏金，说他将向任何发现建议的软分叉中的 “实质性 “缺陷的人提供1万美元。此后，赏金大幅增长，但一些开发者，包括Corallo和Adam Back，传奇赛博朋克和Blockstream的CEO，质疑鲁宾的举措，认为这可能不是获得更多审查者的最佳解决方案。
尽管部分社区对契约有抵触情绪，Poelstra说他相信 “比特币社区对这些想法没有真正的抵触；我们真的只需要个人来支持它们，并在公共交流、工具、测试载体、探索使用案例等方面推进，就像Jeremy对CTV所做的那样。”
除了在Twitter上的激烈讨论，Rubin的提议在比特币开发者邮件列表中得到了更多的正式反馈和问题。最近对CTV做出反馈的开发者包括Michael Folkson, Peter Todd 和Luke Dashjr。Decker也分享了他的想法关于CTV和他的提案之间的交叉点。Poelstra与比特币杂志分享了对CTV的反馈和建议。
“他说：“如果CTV是比特币社区想要走的路，我建议有两种方式来改进它：第一种是改变它的散列结构，使其对更多的一般契约应用有用。“究竟如何做到这一点，相关领域研究很活跃，我希望我们在未来几周会了解更多。也许CTV应该有’Sighash flags'，类似于现有的签名检查的标志”。
“其次，我建议稍微改变CTV，只把交易哈希推到堆栈上，并要求用户使用现有的EQUALVERIFY操作码来检查它是否符合给定的模板，“他补充说。“这将花费普通CTV用户一个字节的交易见证数据，同时为比特币的未来扩展拓宽设计空间。”
另一方面，Rubin告诉《比特币杂志》，他认为，尽管CTV带来的功能有限，但按原样发货更有用，以后再迭代其他功能。
综上所述，尽管BIP119在比特币社区中产生了大量的响应，但升级的路径并不明确。支持者希望增加比特币的功能范围以适应新的用例，这与一些老一辈人更谨慎的做法相冲突。
此外，考虑到比特币的历史上只会推进那些取得压倒性共识并经过彻底审查的升级，当Rubin倡导他的改进建议时，CTV的道路可能会很颠簸。这位开发者已经付出了额外的努力，创建了一个专用网站，提供了大量的资源，让感兴趣的比特币用户了解CTV可以实现的可能性，但他对具有新功能的比特币协议的热情还没有得到比特币发展社区主要人物的祝福。
目前，BIP119看起来停滞不前，在支持为比特币添加令人兴奋的新用例的人与那些在对世界上最具革命性的货币体系进行共识变更之前需要采取更谨慎的方法之间存在压力，该网络应该持续数千年并且不能承受任何失误。
总而言之，要达成共识可能还需要一些时间，但随着该提案在社区成员中获得更多的理解和兴趣，达成共识的道路正在形成。
特别感谢Rubin，他耐心地帮助作者弥补了一些理解上的不足。关于BIP119技术的更详细解释，请观看几年前的这个研讨会（第一部分 和第二部分）。在这个链接上有一份文字记录。其他有用的资源是这个对话、这个播客集和另一个，以及Rubin和Poelstra的对话。要成为BIP119对话的一部分，并听到关于这个问题的最新讨论，加入bitcoin-dev邮件列表。