CheckTemplateVerify (CTV) 旨在提高网络的灵活性，但它的潜在激活是开发人员争论的话题。
CheckTemplateVerify (CTV) 是比特币改进提案 (BIP) 119 中指定的比特币软分叉提案。它旨在通过添加更复杂类型的“契约”或智能合约来为网络启用新的用例，而不是可以目前达到。
为什么要约定？
就目前而言，比特币在基本交易级别的可编程性方面没有很大的灵活性——当然也没有它在用于签署交易的公钥和私钥级别上的灵活性。
推荐阅读 1什么是节点提供商？
2Ethers.js 和 Web3.js 的区别
程序员目前可以使用比特币脚本控制交易的输入，限制在交易花费之前可以做什么，但他们无法控制输出。换句话说，在今天的大多数比特币智能合约中，用户可以通过定义必须满足的限制来控制如何解锁硬币。但是他们无法很好地控制一旦解锁该硬币可以做什么。
例如，可以在交易可以使用时间锁之前定义一定的时间，从而有效地锁定该交易，直到达到指定的块高度。在这种情况下，对何时可以使用资金施加了限制，从而阻止了正确的密钥解锁和使用这些资金。然而，在该时间到期并且在比特币区块链上达到块高度之后，密钥可以解锁这些资金并自由使用它们。
因此，契约有能力通过预先定义哪些输出是可接受的，而不仅仅是控制输入，从而为比特币的编程方式解锁一组新的可能性。尽管具有无限可能性的复杂约定可能会通过潜在地导致意外或意外后果给网络带来安全风险，但 CTV 的提议在很大程度上是简单的。
什么是央视？
简而言之，CTV 允许比特币用户限制他们使用比特币的方式，即使他们拥有想要使用的比特币的密钥。
更重要的是，CTV 允许以非交互方式执行这些支出限制。CTV 支持的一些用例今天可以实现，但大多数时候参与智能合约安排的用户集需要在线并手动交互以协调支出规则，这并不总是可行的。CTV 使这些限制能够以编程方式强制执行，而无需参与者手动交互，从而提高了契约的可靠性。
今天，你可以随心所欲地使用你的 UTXO。在后 CTV 世界中，你可以对你的 UTXO 制定规则，以控制或限制你使用这些代币的可能方式。不是什么时候花费，而是如何花费。通过将这些类型的新功能引入比特币，可以启用更多样化的用例，并且可以出现新的应用生态系统。
CTV 可以为比特币启用的一些功能包括增强安全性、隐私性和可扩展性。随着 CTV 的激活，用户将能够创建更复杂的托管解决方案，例如保险库，这可以让比特币用户预先定义从冷存储到热存储的比特币的预定和有限支出，从而限制潜在黑客造成的损害. CTV 还可以带来支付矿池，这是一种安排，一群人可以共享一个 UTXO 并在他们之间重新平衡资金，这不仅增加了他们的隐私，还为比特币提供了更好的扩展机会。此外，CTV 可以通过改进通道创建和赎回以及哈希时间锁定合约 (HTLC) 来增强闪电网络，
央视如何运作？
在幕后，CTV 为比特币带来了新的操作码，这是比特币脚本中可用操作集的新增功能。
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，由于要检查的交易范围受到限制，因此该约定更容易执行。
操作码 DefaultCheckTemplateVerifyHash 分析的特定散列函数以串行方式散列事务的一部分，从版本和锁定时间开始。接下来，如果交易不是 SegWit 交易，该函数会对 scriptSig 散列进行散列，然后对输入数量、序列散列和输出数量进行散列。最后，该函数对输出的哈希和输入索引进行哈希处理。
通过提前承诺（或确定）其中的大部分，不仅可以预先确定 txID，而且还可以在以后设置其中的少数（具有延展性）并提高验证效率，因为大量字段已经被散列。
BIP119 的作者杰里米·鲁宾 (Jeremy Rubin) 告诉比特币杂志：“以特定方式对字段进行排序的想法是，如果在未来某个时候你在比特币中有类似 OP_CAT 的东西，你可能会在堆栈上操纵这些东西。” “按照你以编程方式更改它们的可能性来排序，它们有一些好处。”
“因此，部分想法是 nVersion 最不可能被改变，输入索引最有可能被改变，而其他一切都按这个顺序落在中间，”鲁宾补充道。
假设一个比特币开发者编写一个契约比输入更可能以编程方式更改输出信息，因为契约试图限制如何使用硬币。
因此，OP_CHECKTEMPLATEVERIFY 所做的是检查事务是否被允许。换句话说，它强制执行由 Sapio 编写的契约所施加的限制。
但该检查仅在堆栈上的元素大小为 32 字节时才会发生。如果没有，CTV 将对堆栈上的元素进行 OP_NOP，这意味着它不会执行失败，而是“什么也不做”。
这种微妙的差异旨在适应 CTV 之后可能构建的未来发展，例如，向其添加标志字节的“CTV 版本 2”——使元素为 33 个字节。然后，不是使用 CTV 来检查它，因为它只检查 32 字节的元素，该元素将由检查 33 字节的“CTV 版本二”检查。这是可能的，因为 OP_NOP 使脚本评估能够继续。如果它失败了，评估将不会继续，因此该元素将不会根据“CTV 版本 2”进行检查。
CTV会是比特币的下一个升级吗？
比特币升级过程以其有条不紊和谨慎的方法而闻名，这是网络生存的一个重要特征，以及确保每个新添加代码的正确性。因此，目前还不清楚 CTV 是否会很快被添加到比特币中。
虽然不是一个新提案——BIP 是在 2020 年 1 月创建的——但著名的比特币开发人员认为，需要围绕建议的更改进行更广泛的测试和讨论，尤其是在涉及可能的优化和更详细地考虑替代方案时。
在撰写本文时，CTV 将为比特币增加一组有限的新可能性，因为它试图在协议中实施一种低风险的契约形式。鲁宾告诉比特币杂志，我们的目标是发布一些能够为比特币启用新功能的东西，同时“就我们曾经做过的比特币验证的影响而言，它很可能是最简单的软分叉之一”。
鲁宾补充说，他觉得开发者社区在审查他的提案时“有点双重标准”。“这是 CTV 比我们以前所做的任何事情都要高得多的标准，”他告诉比特币杂志。
本月早些时候，Spiral 的比特币和闪电网络开发人员 Matthew Corallo 在推特上写道：“在比特币的历史上，任何时候都不能提议将事情达成共识……而不考虑替代方案。” Corallo 声称，在过去的几年里，鲁宾以及那些致力于 CTV 和支持 CTV 的人未能展示“一种更正式的方法来将其与替代品进行比较”。
“对 CTV 的推动感觉……几乎在各个方面都是错误的，”Corallo 补充道。“而不是协作工程，感觉就像’我建造了这个，让我们去做’，而忽略任何反馈。”
Blockstream 的研究主管 Andrew Poelstra 也渴望进行进一步的实验和分析。当被问及 CTV 是否是比特币目前扩展功能以支持契约的最佳选择时，他告诉比特币杂志，他“不建议”，并补充说“CTV 并不是在比特币中实施契约的唯一提议方式——而且它达到了在安全性和通用性之间进行权衡，从而在任一方向上都留有空间。”
“可行的一种方法是，CTV 可能是实施‘减法契约’的最有效方式，在这种契约中，用户限制了大部分交易数据，而只保留了一小部分免费数据，”Poelstra 说。“与此同时，内省操作码等其他建议可能最适合‘附加契约’，其中大部分交易数据是免费的，只有少量受到限制。如果这是真的，并且社区需要更多时间来探索这一点，那么我们实际上会想要 APO 和 CTV 以及通用契约。”
APO 或 OP_ANYPREVOUT 是 BIP118 中指定的为比特币添加新功能的另一个提议。它的作者、Blockstream 专注于比特币扩展解决方案的研究员 Christian Decker 告诉比特币杂志，他还认为 APO 和 CTV 是对比特币的“补充而非竞争”。
“两者都是有益的，”德克尔说。“所以我同意，当它们都准备好、经过审查和测试时，我们应该一起激活它们。”
目前，激活准备是比特币社区的一个微妙话题。事实上，一些开发商对 CTV 的抵制部分是基于 CTV 支持者所描绘的一种所谓的紧迫感。如果尚未准备好的更改最终被添加到比特币的代码中，那么仓促部署可能是有害的。
Decker 告诉比特币杂志，如果这意味着要采用更强大的测试流程，他愿意等待更长时间将他的提案添加到比特币中，尽管他说他理解 CTV 支持者希望尽快启动的愿望。
“我们认为推动变革没有好处，需要紧急部署 APO，”Decker 说。“提案可以炖的时间越长，审查它并突出潜在弱点的眼睛就越多。审查员和开发人员的时间是比特币最稀有的资源，因此我们希望尊重这一点，尽管有一些 eltoo 的 [概念证明] 实施。”
2021 年 12 月，为了吸引更多人关注他的提议，鲁宾为 CTV 及其指定的 BIP 设置了漏洞赏金，称他将向在建议的软分叉中发现“重大”缺陷的任何人提供 10,000 美元。此后，赏金大幅增长，但包括 Corallo 和传奇密码朋克兼 Blockstream 首席执行官 Adam Back 在内的一些开发人员质疑 Rubin 的倡议，认为这可能不是获得更多评测者的最佳解决方案。
尽管社区部分人反对契约，但 Poelstra 表示，他相信“比特币社区对这些想法没有真正的抵抗；我们真的只需要个人支持他们并推动公共交易所、工具、测试向量、探索用例等，就像 Jeremy 对 CTV 的方式一样。”
除了 Twitter 上的激烈讨论外，Rubin 的提议在比特币开发者邮件列表中收到了更多正式的反馈和问题。最近对 CTV 提供反馈的开发人员包括 Michael Folkson、Peter Todd 和 Luke Dashjr。德克尔还分享了他对 CTV 和他的提议之间的交叉点的看法。Poelstra 与比特币杂志分享了对 CTV 的反馈和建议。
“如果 CTV 是比特币社区想要的方式，那么我建议通过两种方式对其进行改进：第一种是改变其哈希结构，以便对更一般的契约应用程序有用，”他说。“确切地说，如何做到这一点是一个活跃的研究领域，我希望我们能在未来几周内了解更多。也许 CTV 应该有类似于现有标志的‘sighash 标志’，用于签名检查。”
“其次，我建议稍微改变 CTV，仅将交易哈希推送到堆栈上，并要求用户使用现有的 EQUALVERIFY 操作码来检查它是否与给定模板匹配，”他补充道。“这将使普通 CTV 用户花费一个字节的交易见证数据，同时扩大比特币未来扩展的设计空间。”
另一方面，鲁宾告诉比特币杂志，他认为按原样发布 CTV 更有用，尽管它带来了有限的功能，并在以后迭代附加功能。
总而言之，尽管 BIP119 在比特币社区中引起了广泛关注，但拟议升级的未来路径尚不清楚。支持者希望增加比特币的功能范围以适应新的用例，这与一些老前辈更谨慎的做法发生了冲突。
此外，鉴于比特币的历史只推动取得压倒性共识并经过彻底审查的升级，当鲁宾试图倡导他的改进建议时，CTV 的前进道路可能会崎岖不平。开发人员在创建一个拥有大量资源的专用网站方面付出了更多努力，以向感兴趣的比特币用户宣传 CTV 可以实现的可能性，但他对具有新功能的比特币协议的热情尚未得到业内主要人物的祝福。比特币开发社区。
目前，BIP119 看起来停滞不前，夹在支持为比特币添加令人兴奋的新用例的人和那些需要在世界上最具革命性的货币体系（一个应该持续数千年的网络不能承受任何失误。
总而言之，这两个群体可能需要一段时间才能达成协议，但随着该提案在社区成员中获得更多理解和兴趣，正在为达成共识铺平道路。
特别感谢鲁宾，他耐心地帮助作者弥合了他理解上的一些空白。有关 BIP119 技术的更详细说明，请观看几年前的这个研讨会（第一部分和第二部分）。此链接上提供了成绩单。其他有用的资源是这个对话、这个播客片段和另一个。要参与有关 BIP119 的对话并听取有关此问题的最新讨论，请加入比特币开发邮件列表。
关注微信
