在它们冷却之前:生产中的契约 Nn Liquid

By Bitcoin 杂志 - 6 个月前 - 阅读时间:6 分钟

在它们冷却之前:生产中的契约 Nn Liquid

从那以后, Bitcoin community embarked on discussions surrounding the optimization of covenants, there's been a growing interest in learning more about their tradeoffs and the covenants already deployed on the 液体网络.

In light of this renewed interest and to encourage further discussion, let's review some of Liquid's current covenant offerings, comparing them with the leading proposals on Bitcoin and examining their respective use cases.

Liquid 契约的历史

Covenants on Liquid can be traced back to the deployment of the first Elements sidechain, 阿尔法. This sidechain introduced the opcodes OP_CHECKSIGFROMSTACK (CSFS) and OP_DETERMINISTICRANDOM along with a number of others to Elements. Alpha also enabled fixed versions of opcodes disabled in early Bitcoin,如 OP_CAT—an opcode many are choosing to revisit in the growing dialogue across social media. These new opcodes further improved the expressivity of the version of Bitcoin Script available in Elements, and a proof-of-concept Möser-Eyal-Sirer vault was developed utilizing CSFS to illustrate the new possibilities.

实施 CSFS 的经验之一是,它要求在执行契约支出时将交易数据推送到堆栈上,从而使契约变得更加复杂。 从开发人员的经验中还观察到,使用 CSFS 契约,构成签名哈希的交易数据必须在堆栈上重建,这可能会迫使开发人员推送与他们感兴趣的交易输入/输出无关的数据。

To simplify covenant construction, more than 30 new opcodes called 自省操作码 were introduced in Liquid’s Taproot 升级 for a more modular approach. Introspection opcodes with CSFS, for example, enable the inspection of more granular parts of the transaction during a spend by placing it on the stack. This alleviates the responsibility of assembling partial transaction data via the witness and, therefore, the signature hash on the stack.

主要契约提案

目前,该 Bitcoin community is discussing a laundry list of potential covenant proposals, including SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, the MATT opcode OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT, and OP_CHECKTEMPLATEVERIFY (CTV). 简单, a next-generation scripting language that could implement functionality similar to many covenants at a lower level, is also a potential route for Bitcoin (we'll revisit this later).

There has been a lot of talk about the VAULT opcode, which was created to address the need for easier ways to secure bitcoin for users. This opcode would allow coins to be locked in an address that can only spend to two addresses: a hot wallet after a timelock or immediately to a cold wallet. Several other variant schemes have been proposed, but they depend on adopting CTV first.

CTV 是一种操作码,它从堆栈中读取哈希值并将其与支出交易数据的指定子集的哈希值进行比较。 它的灵活性有望支持多种应用程序,包括但不限于:拥塞控制、保险库和基本支付池。

Apart from opcodes, there have been proposals for sighashes to enable covenants. The two most popular proposals for this purpose are APO and SIGHASH_GROUP. APO is an evolution of the SIGHASH_NOINPUT opcode, which is widely recognized as a prerequisite for implementing 埃尔图. One of the many improvements made possible with eltoo is the elimination of the penalty mechanism that forces the other party to forfeit funds when broadcasting an outdated channel state. This allows for a more user-friendly and efficient Lightning Network.

使用 Liquid 操作码实现类似的功能

While Liquid doesn't have the CTV and VAULT opcodes, it does have CSFS and 喵星人 for covenants. By using these more narrowly defined opcodes with the aforementioned introspection opcodes, developers have opened up new financial possibilities with functionality similar to CTV and VAULT to augment the sidechain.

For example, Burak, a seasoned Liquid developer and creator of the layer-2 protocol Ark, has demonstrated an emulation of VAULT using Liquid covenant opcodes in one discussion with James O’Beirne on X.

Similarly, a way to achieve APO functionality was made possible with CSFS. This 演示 utilized various opcodes that would enable layer-2 protocols like eltoo on Liquid today but suffers from added complexity and a larger transaction size compared to the proposed usage of the APO-type covenant. Moreover, the construction doesn't apply to Taproot transactions, which would introduce its own form of added complexity.

Liquid 操作码的实际应用

Many applications have already taken advantage of covenant opcodes on Liquid. Steven Roose, a covenant proponent who recently 定义 a specification for the previously ideated OP_TXHASH, has developed an 应用的区域 for fidelity bonds on Liquid. This covenant is placed on funds that would be burned if evidence of a double spend is presented in the witness.

富士钱’s Fuji USD (FUSD), an algorithmic stablecoin developed by Vulpem Ventures is another notable example. It relies purely on oracle information to maintain its peg and can be issued in a decentralized manner. It uses a 组合 of signature verifications and introspection opcodes to accomplish this, and the most important part is it’s all auditable on chain.

Other applications of covenants on Liquid include options contracts and confidential asset-based loans. The Blockstream Research team released a 白皮书 last year (see accompanying 博客文章) about the former, explaining how such an options contract could be constructed using the new set of introspective opcodes.These new opcodes allow users to trustlessly create tokens representing both sides of a covered call option contract and sell the opposite position they wish to take. Contracts made in this fashion also support partial fills, meaning the user who created the contract can sell positions representing a multiple of a user-specified minimum amount of the collateral asset, called the ‘contract size.’

为什么不先使用液体?

作为 Bitcoin ecosystem continues to have a healthy debate regarding covenant opcodes, Liquid offers its own set of tools, catering to similar objectives but with distinct implementations. As the dialogue evolves, it'll be intriguing to witness the interplay between Bitcoin's native proposals and Liquid's already concrete and live covenant-related features and emulation of Bitcoin covenant proposals implemented using Elements Script.

Another new technology on the horizon is 简单, a verifiable programming language for the blockchain. The Simplicity language is defined by operations with very narrow semantics that can make expressive programs when composed together. The language is also verifiable, which means methods can be established to mathematically prove assertions made on Simplicity programs.

Simplicity's expressive nature allows covenant opcodes from Script to be seamlessly ported, ensuring greater reliability and fewer unexpected behaviors. Bitcoin 研究员 桑克特·坎加尔卡 has already done this work for CTV. Using s-lang, a more readable Bitcoin-centric programming language that compiles down to Simplicity, he was able to replicate the semantics in a workable proof-of-concept available for anyone to try today.

Bitcoin developers will soon have the opportunity to use s-lang in a real environment thanks to Liquid's integration of Simplicity, targeted for Q2 2024. s-lang will bring the construction of more complex applications to Liquid, such as vaults and delegation. The draft PR is available for review at the following 链接.

随着 悠久的历史 of Liquid as an early adopter of ideas that have been later ported to Bitcoin, a suggestion for those looking to showcase the viability of their proposals is to try it live on Liquid to validate ideas first—as multiple covenant-related opcodes have been shown to be emulatable using existing Liquid covenant and introspection opcodes.

So, the next time someone suggests a new covenant, it's worth asking: why not try it on Liquid first?

这是一个客户后,由 兰迪·纳尔。 所表达的观点完全是他们自己的观点,并不一定反映BTC Inc或 Bitcoin 杂志。

原始来源: Bitcoin 杂志