自从比特币社区开始围绕契约的优化展开讨论以来，人们越来越有兴趣了解更多关于契约的权衡以及已经部署在液体网络上的契约。
鉴于这种新的兴趣并为了鼓励进一步的讨论，让我们回顾一下 Liquid 目前提供的一些契约，将它们与比特币的主要提案进行比较，并研究它们各自的使用案例。
液体公约的历史
Liquid 上的契约可以追溯到首个 Elements 侧链 Alpha 的部署。该侧链引入了 OP_CHECKSIGFROMSTACK (CSFS) 和 OP_DETERMINISTICRANDOM 操作码以及其他一些操作码。Alpha 还启用了在早期比特币中被禁用的操作码的固定版本，例如 OP_CAT--在社交媒体上日益增多的对话中，许多人都选择重新讨论这个操作码。这些新操作码进一步提高了元素中可用的比特币脚本版本的表现力，并利用 CSFS 开发了一个概念验证 Möser-Eyal-Sirer 金库，以展示新的可能性。
实施 CSFS 的经验之一是，在执行契约花费时，需要将事务数据推送到堆栈，从而使契约变得更加复杂。从开发人员的经验中还发现，使用 CSFS 契约时，必须在堆栈上重建构成签名哈希的事务数据，这可能会迫使开发人员推送与他们感兴趣的事务输入/输出无关的数据。
为了简化契约的构建，Liquid 的 Taproot 升级版引入了 30 多个新的操作码（称为自省操作码），以实现更模块化的方法。例如，使用 CSFS 的自省操作码可以在花费期间，通过将其放在堆栈中来检查交易的更细粒度部分。这就减轻了通过见证组装部分交易数据的责任，因此也减轻了堆栈上的签名哈希值的责任。
领先的盟约提案
目前，比特币社区正在讨论一系列潜在的契约建议，包括 SIGHASH_ANYPREVOUT (APO)、OP_TXHASH、CSFS、OP_CAT、OP_TLUV、MATT 操作码 OP_CHECKCONTRACTVERIFY (CCV)、OP_VAULT 和 OP_CHECKTEMPLATEVERIFY (CTV)。Simplicity 是一种下一代脚本语言，可以在较低层次上实现与许多契约类似的功能，它也是比特币的一种潜在途径（我们将在以后再次讨论）。
Blockstream 研究团队的 Christian Lewe 讨论了 Simplicity 及其对组合器和喷射器的使用，以及如何通过单一软分叉实现 CTV 和 APO 等流行契约的功能。
关于 VAULT 操作码的讨论已经很多了，它的出现是为了满足用户对更简便的比特币安全方式的需求。该操作码允许将比特币锁定在一个地址中，而该地址只能向两个地址消费比特币：一个是经过时间锁定的热钱包，另一个是立即消费的冷钱包。其他一些变体方案也已被提出，但它们都依赖于首先采用 CTV。
CTV 是一种操作码，可从堆栈中读取哈希值，并将其与支出交易数据指定子集的哈希值进行比较。它具有灵活性，可支持多种应用，包括但不限于：拥塞控制、保险库和基本支付池。
除操作码外，还有一些关于 sighashes 的建议，以启用契约。为此提出的两个最流行的建议是 APO 和 SIGHASH_GROUP。APO 是 SIGHASH_NOINPUT 操作码的演变，而 SIGHASH_NOINPUT 操作码被公认为是实现 eltoo 的先决条件。eltoo 的众多改进之一是取消了在广播过时信道状态时迫使对方放弃资金的惩罚机制。这使得闪电网络更加方便易用，效率更高。
利用液体操作码实现类似功能
虽然 Liquid 没有 CTV 和 VAULT 操作码，但它有用于契约的 CSFS 和 CAT。通过使用这些定义较窄的运算法则和上述反省运算法则，开发人员利用类似于 CTV 和 VAULT 的功能为增强侧链开辟了新的金融可能性。
例如，经验丰富的 Liquid 开发人员兼第 2 层协议 Ark 的创建者布拉克（Burak）在与詹姆斯-奥贝恩（James O'Beirne）关于 X 的一次讨论中，演示了使用 Liquid 约定操作码模拟 VAULT。
同样，利用 CSFS 也可以实现 APO 功能。该演示使用了各种操作码，可以在目前的 Liquid 上实现 eltoo 等第二层协议，但与建议使用的 APO 类型协约相比，复杂性更高，事务规模更大。此外，该结构不适用于 Taproot 交易，而 Taproot 交易本身也会增加复杂性。
液体操作码的实际应用
许多应用程序已经利用了 Liquid 上的契约操作码。最近为之前设想的 OP_TXHASH 定义规范的契约支持者 Steven Roose，已经在 Liquid 上开发了一个保真债券应用程序。如果证人出示了双重消费的证据，该契约就会被置于资金之上。
富士货币公司的富士美元（FUSD）是 Vulpem Ventures 开发的算法稳定币，是另一个值得注意的例子。它纯粹依靠甲骨文信息来维持挂钩，可以去中心化的方式发行。它采用签名验证和反省操作码相结合的方式来实现这一目标，最重要的是，这一切都可以在链上进行审计。
液体契约的其他应用包括期权合约和保密资产贷款。区块流研究团队去年发布了一份关于前者的白皮书（见所附博文），解释了如何使用一套新的自省操作码来构建这样的期权合约。这些新的操作码允许用户以可信的方式创建代表备兑看涨期权合约双方的代币，并卖出他们希望持有的相反头寸。以这种方式创建的合约还支持部分成交，这意味着创建合约的用户可以卖出代表用户指定的抵押资产最低金额（称为 "合约规模"）倍数的头寸。
了解有关 Liquid 上可用的操作码契约以及它们如何实现原子交换的更多信息。该视频介绍了原子交换的历史，举例说明了以不同身份使用原子交换的一些服务和产品，并探讨了使用名为 LiquidJS 的库制作这些类型的契约所需的类型脚本代码。
为什么不首先使用液体？
随着比特币生态系统继续就盟约操作码展开健康的讨论，Liquid 也提供了自己的一套工具，以满足类似的目标，但又有不同的实现方式。随着对话的发展，见证比特币的原生提议与 Liquid 已经具体化的、实时的契约相关功能之间的相互作用，以及使用 Elements Script 实现的比特币契约提议的仿真，将是一件非常有趣的事情。
另一项即将问世的新技术是简化语言（Simplicity），这是一种用于区块链的可验证编程语言。Simplicity 语言是由语义非常狭窄的操作定义的，这些操作组成的程序具有很强的表现力。这种语言也是可验证的，这意味着可以建立方法，用数学方法证明在 Simplicity 程序上做出的断言。
Simplicity 的表现力允许无缝移植脚本中的代码，从而确保更高的可靠性和更少的意外行为。比特币研究员 Sanket Kanjalkar 已经为 CTV 完成了这项工作。使用 s-lang（一种以比特币为中心的更易读的编程语言，可编译为 Simplicity），他能够在一个可行的概念验证中复制语义，任何人今天都可以尝试。
比特币开发者将很快有机会在实际环境中使用s-lang，这要归功于Liquid对Simplicity的整合，目标是在2024年第二季度。可通过以下链接查看 PR 草案。
长期以来，Liquid 一直是那些后来被移植到比特币上的想法的早期采用者，因此，对于那些希望展示其提议可行性的人来说，一个建议就是先在 Liquid 上进行实时尝试，以验证其想法--因为多个与盟约相关的操作码已被证明可以使用现有的 Liquid 盟约和反省操作码进行仿真。
因此，下一次有人建议制定新盟约时，不妨问一问：为什么不先在 Liquid 身上试一试呢？
本文的早期版本最初发布在《比特币杂志》上： https://bitcoinmagazine.com/technical/before-they-were-cool-covenants-in-production-on-liquid