自从比特币社区开始围绕契约优化进行讨论以来,人们越来越有兴趣了解更多关于其权衡和已经部署在比特币上的契约。 液体网络。
鉴于这种新的兴趣并鼓励进一步讨论,让我们回顾一下 Liquid 目前的一些契约产品,将它们与比特币的主要提案进行比较,并研究它们各自的用例。
Liquid 契约的历史
Liquid 上的契约可以追溯到第一个 Elements 侧链的部署, Α。 该侧链向 Elements 引入了操作码 OP_CHECKSIGFROMSTACK (CSFS) 和 OP_DETERMINISTICRANDOM 以及其他一些操作码。 Alpha 还启用了早期比特币中禁用的操作码的固定版本,例如 OP_CAT——在社交媒体上日益增长的对话中,许多人选择重新审视这个操作码。 这些新的操作码进一步提高了 Elements 中可用的比特币脚本版本的表现力,并进行了概念验证 莫塞尔-埃亚勒-西雷尔金库 利用 CSFS 开发来说明新的可能性。
实施 CSFS 的经验之一是,它要求在执行契约支出时将交易数据推送到堆栈上,从而使契约变得更加复杂。 从开发人员的经验中还观察到,使用 CSFS 契约,构成签名哈希的交易数据必须在堆栈上重建,这可能会迫使开发人员推送与他们感兴趣的交易输入/输出无关的数据。
为了简化契约的构建,超过 30 个新的操作码被称为 自省操作码 在 Liquid 的 Taproot 中引入 升级 采用更加模块化的方法。 例如,CSFS 的自省操作码可以通过将交易放在堆栈上来在支出期间检查交易的更细粒度部分。 这减轻了通过见证人组装部分交易数据的责任,从而减轻了堆栈上签名哈希的责任。
主要契约提案
目前,比特币社区正在讨论一系列潜在的契约提案,包括 SIGHASH_ANYPREVOUT (APO)、OP_TXHASH、CSFS、OP_CAT、OP_TLUV、MATT 操作码 OP_CHECKCONTRACTVERIFY (CCV)、OP_VAULT 和 OP_CHECKTEMPLATEVERIFY (CTV)。 简单,一种下一代脚本语言,可以在较低级别实现与许多契约类似的功能,也是比特币的潜在途径(我们稍后会重新讨论)。
关于 VAULT 操作码已经有很多讨论,它的创建是为了满足用户以更简单的方式保护比特币的需求。 该操作码将允许将代币锁定在只能花费到两个地址的地址中:时间锁定后的热钱包或立即到冷钱包。 已经提出了其他几种变体方案,但它们取决于首先采用 CTV。
CTV 是一种操作码,它从堆栈中读取哈希值并将其与支出交易数据的指定子集的哈希值进行比较。 它的灵活性有望支持多种应用程序,包括但不限于:拥塞控制、保险库和基本支付池。
除了操作码之外,还有人提出使用叹息来启用契约。 为此目的,两个最流行的提案是 APO 和 SIGHASH_GROUP。 APO 是 SIGHASH_NOINPUT 操作码的演变,它被广泛认为是实现的先决条件 埃尔图。 eltoo 实现的众多改进之一是消除了在广播过时的频道状态时迫使另一方放弃资金的惩罚机制。 这使得闪电网络更加用户友好和高效。
使用 Liquid 操作码实现类似的功能
虽然 Liquid 没有 CTV 和 VAULT 操作码,但它有 CSFS 和 猫 为了契约。 通过将这些更狭义定义的操作码与上述内省操作码一起使用,开发人员开辟了新的金融可能性,其功能类似于 CTV 和 VAULT 来增强侧链。
例如,Burak 是一位经验丰富的 Liquid 开发人员,也是第 2 层协议 Ark 的创建者,他展示了 VAULT 模拟 在与 James O’Beirne 的一次讨论中使用 Liquid 契约操作码 X。
类似地,CSFS 使实现 APO 功能的方法成为可能。 这 演示 使用了各种操作码,这些操作码可以在 Liquid 上启用像 eltoo 这样的第 2 层协议,但与 APO 类型契约的建议使用相比,其复杂性增加,交易规模更大。 此外,该构造不适用于 Taproot 交易,这会引入其自身形式的增加复杂性。
Liquid 操作码的实际应用
许多应用程序已经利用了 Liquid 上的契约操作码。 史蒂文·罗斯 (Steven Roose),圣约支持者,最近 定义的 先前设想的 OP_TXHASH 规范已开发出 应用 用于 Liquid 上的保真债券。 如果证人出示双重支出的证据,该契约将被烧毁。
富士钱富士美元 (FUSD) 是 Vulpem Ventures 开发的一种算法稳定币,也是另一个著名的例子。 它纯粹依靠预言机信息来维持其挂钩,并且可以以去中心化的方式发行。 它使用一个 组合 签名验证和自省操作码来实现这一点,最重要的部分是它在链上都是可审计的。
Liquid 契约的其他应用包括期权合约和 保密资产贷款。 Blockstream 研究团队发布了 白皮书 去年(见附表 博客文章)关于前者,解释了如何使用一组新的内省操作码构建这样的期权合约。这些新操作码允许用户无需信任地创建代表备兑看涨期权合约双方的代币,并出售他们希望持有的相反头寸。 以这种方式制定的合约还支持部分填充,这意味着创建合约的用户可以出售代表用户指定的最低抵押资产金额(称为“合约规模”)倍数的头寸。
为什么不先使用液体?
随着比特币生态系统继续就契约操作码展开健康的辩论,Liquid 提供了自己的一套工具,迎合类似的目标,但具有不同的实现方式。 随着对话的发展,见证比特币的原生提案与 Liquid 已经具体且实时的契约相关功能以及使用 Elements Script 实现的比特币契约提案的模拟之间的相互作用将会很有趣。
另一项即将出现的新技术是 简单,一种可验证的编程语言 区块链。 Simplicity 语言是由语义非常狭窄的操作定义的,这些操作组合在一起可以生成富有表现力的程序。 该语言也是可验证的,这意味着可以建立方法来从数学上证明对 Simplicity 程序所做的断言。
简单性的表现力使得来自脚本的契约操作码能够无缝移植,确保更高的可靠性和更少的意外行为。 比特币研究员 桑克特·坎加尔卡 已经为CTV完成了这项工作。 使用 只是s-,一种更具可读性的以比特币为中心的编程语言,可以编译成简单性,他能够以可行的概念验证方式复制语义,供任何人今天尝试。
由于 Liquid 计划于 2024 年第二季度集成 Simplicity,比特币开发人员很快将有机会在真实环境中使用 s-lang。s-lang 将为 Liquid 带来更复杂应用程序的构建,例如金库和委托。 PR 草案可在以下网址进行审核: 关联。
与一个 悠久的历史 Liquid 作为后来移植到比特币的想法的早期采用者,对于那些希望展示其提案可行性的人的建议是首先在 Liquid 上尝试以验证想法 – 因为多个与契约相关的操作码已被证明可以可使用现有的 Liquid 契约和内省操作码进行模拟。
因此,下次有人建议新契约时,值得一问:为什么不先在 Liquid 上尝试呢?
这是一篇客座帖子 杜兰迪。 所表达的观点完全是他们自己的,并不一定反映 BTC Inc 或比特币杂志的观点。