By Bitcoin 雑誌-6ヶ月前-読書時間：6分
冷める前に: Covenants in Production Nn Liquid
それ以来、 Bitcoin コミュニティがコベナントの最適化を巡る議論に乗り出し、そのトレードオフやすでにデプロイされているコベナントについてさらに知りたいという関心が高まっています。 液体ネットワーク.
この新たな関心を踏まえ、さらなる議論を促すために、Liquid の現在の契約提案のいくつかを検討し、主要な提案と比較してみましょう。 Bitcoin それぞれのユースケースを検討します。
液体に関する規約の歴史
Liquid に関する規約は、最初の Elements サイドチェーンのデプロイメントにまで遡ることができます。 アルファ。 このサイドチェーンは、オペコード OP_CHECKSIGFROMSTACK (CSFS) と OP_DETERMINISTICRANDOM を他の多数のオペコードとともに Elements に導入しました。 アルファ版では、初期に無効になっていたオペコードの修正バージョンも有効になりました Bitcoin、 といった OP_CAT—ソーシャルメディア全体で拡大する対話の中で、多くの人が再検討することを選択しているオペコードです。 これらの新しいオペコードにより、バージョンの表現力がさらに向上しました。 Bitcoin Elements で利用可能なスクリプトと概念実証 メーザー・エヤル・シレール保管庫 は、新しい可能性を示すために CSFS を利用して開発されました。
CSFS の実装から学んだことの XNUMX つは、コベナントの支出を実行するときにトランザクション データをスタックにプッシュする必要があるため、コベナントがより複雑になるということでした。 また、開発者の経験から、CSFS コベナントでは、署名ハッシュを構成するトランザクション データをスタック上で再構築する必要があり、開発者が関心のあるトランザクションの入出力に無関係なデータをプッシュする必要がある可能性があることが観察されました。
コベナントの構築を簡素化するために、30 を超える新しいオペコードが呼び出されました。 イントロスペクションオペコード LiquidのTaprootで紹介されました アップグレード よりモジュール化されたアプローチのために。 たとえば、CSFS を使用したイントロスペクション オペコードは、トランザクションをスタックに配置することで、支出中にトランザクションのより詳細な部分を検査できるようにします。 これにより、証人を介して部分的なトランザクション データを組み立てる責任が軽減され、したがってスタック上の署名ハッシュが軽減されます。
主要な規約提案
現在、 Bitcoin コミュニティでは、SIGHASH_ANYPREVOUT (APO)、OP_TXHASH、CSFS、OP_CAT、OP_TLUV、MATT オペコード OP_CHECKCONTRACTVERIFY (CCV)、OP_VAULT、および OP_CHECKTEMPLATEVERIFY (CTV) を含む、潜在的な規約提案の膨大なリストについて議論しています。 単純、多くの規約と同様の機能を下位レベルで実装できる次世代スクリプト言語も、潜在的なルートです。 Bitcoin (これについては後でもう一度説明します)。
VAULT オペコードについては多くの話題があり、これはセキュリティをより簡単に保護する方法の必要性に対処するために作成されました。 bitcoin ユーザーにとって。 このオペコードにより、コインを XNUMX つのアドレス (タイムロック後のホット ウォレット、またはすぐにコールド ウォレット) にのみ使用できるアドレスにロックできるようになります。 他にもいくつかの変形スキームが提案されていますが、それらは最初に CTV を採用することに依存しています。
CTV は、スタックからハッシュを読み取り、それを支出トランザクション データの指定されたサブセットのハッシュと比較するオペコードです。 その柔軟性により、輻輳制御、保管庫、基本的な支払いプールなど (ただしこれらに限定されない) さまざまなアプリケーションの使用が可能になります。
オペコードとは別に、コベナントを有効にするための sighash の提案もあります。 この目的で最も一般的な XNUMX つの提案は、APO と SIGHASH_GROUP です。 APO は SIGHASH_NOINPUT オペコードの進化版であり、実装の前提条件として広く認識されています。 エルトゥー。 eltoo で可能になった多くの改善点の XNUMX つは、古いチャネル状態をブロードキャストするときに相手に資金の没収を強制するペナルティ メカニズムの削除です。 これにより、よりユーザーフレンドリーで効率的な Lightning ネットワークが実現します。
Liquid オペコードで同様の機能を実現
Liquid には CTV および VAULT オペコードはありませんが、CSFS と VAULT オペコードはあります。 CAT 誓約のため。 これらのより狭く定義されたオペコードを前述のイントロスペクション オペコードとともに使用することにより、開発者は CTV や VAULT と同様の機能を備えたサイドチェーンを強化する新たな金融の可能性を切り開きました。
たとえば、ベテランの Liquid 開発者であり、レイヤー 2 プロトコル Ark の作成者である Burak 氏は、 VAULTのエミュレーション James O'Beirne とのディスカッションで Liquid Covenant オペコードを使用 X.
同様に、APO 機能を実現する方法は CSFS によって可能になりました。 これ デモ 現在の Liquid 上で eltoo のようなレイヤー 2 プロトコルを可能にするさまざまなオペコードを利用していますが、提案されている APO タイプ規約の使用法と比較して、複雑さが増し、トランザクション サイズが大きくなるという問題があります。 さらに、この構造は Taproot トランザクションには適用されないため、独自の形式の複雑さが追加されます。
Liquid オペコードの動作
多くのアプリケーションがすでに Liquid 上のコベナント オペコードを利用しています。 スティーブン・ルースは最近、規約の支持者であり、 定義済みの 以前に考案された OP_TXHASH の仕様が開発されました。 Liquid 上の忠実度ボンドの場合。 この規約は、二重支出の証拠が証人に提出された場合に焼却される資金に適用されます。
フジマネーVulpem Ventures が開発したアルゴリズムのステーブルコインである Fuji USD (FUSD) も注目すべき例です。 ペッグを維持するために純粋にオラクル情報に依存しており、分散型で発行できます。 それは、 組み合わせ これを達成するための署名検証とイントロスペクション オペコードが含まれますが、最も重要な部分は、すべてがチェーン上で監査可能であることです。
リキッドに関する規約のその他の適用には、オプション契約や 機密資産ベースのローン。 ブロックストリーム研究チームは、 ホワイトペーパー 昨年（添付資料を参照） ブログ投稿) 前者については、内省的なオペコードの新しいセットを使用してそのようなオプション契約をどのように構築できるかを説明しています。これらの新しいオペコードを使用すると、ユーザーはカバーされたコール オプション契約の両側を表すトークンをトラストレスに作成し、希望する反対のポジションを売ることができます。 この方法で作成された契約は部分約定もサポートしています。つまり、契約を作成したユーザーは、「契約サイズ」と呼ばれる、ユーザーが指定した担保資産の最小額の倍数を表すポジションを売却できます。
なぜリキッドファーストではないのか？
として Bitcoin エコシステムではコベナント オペコードに関する健全な議論が継続されており、Liquid は同様の目的に応える独自のツール セットを提供していますが、実装は異なります。 対話が進むにつれ、両者の間の相互作用を目撃するのは興味深いものになるでしょう。 Bitcoinのネイティブの提案と、Liquid のすでに具体的でライブな契約関連の機能とエミュレーション Bitcoin Elements Script を使用して実装された規約の提案。
もう一つの新技術が登場予定です。 単純、のための検証可能なプログラミング言語。 ブロックチェーン。 Simplicity 言語は、非常に狭いセマンティクスの操作によって定義されており、これらを組み合わせて構成すると表現力豊かなプログラムを作成できます。 この言語は検証可能でもあり、Simplicity プログラムで行われたアサーションを数学的に証明する方法を確立できることを意味します。
Simplicity の表現力豊かな性質により、スクリプトからのコベナント オペコードをシームレスに移植できるため、信頼性が向上し、予期しない動作が少なくなります。 Bitcoin 研究者 サンケット・カンジャルカール はすでに CTV に対してこの作業を行っています。 使用する スラング、より読みやすい BitcoinSimplicity にコンパイルされる - 中心のプログラミング言語を使用して、誰でも今日から試すことができる実行可能な概念実証でセマンティクスを再現することができました。
Bitcoin 2 年第 2024 四半期に予定されている Liquid の Simplicity 統合のおかげで、開発者は間もなく実際の環境で s-lang を使用できるようになります。s-lang は、ボールトや委任など、より複雑なアプリケーションの構築を Liquid にもたらします。 PR 草案は以下で確認できます。 .
とともに 長い歴史 後に移植されたアイデアの早期採用者としての Liquid の Bitcoin、提案の実行可能性を示したいと考えている人への提案は、最初にアイデアを検証するために Liquid 上でライブで試してみることです。複数のコベナント関連のオペコードが、既存の Liquid コベナントおよびイントロスペクション オペコードを使用してエミュレートできることが示されているためです。
したがって、次回誰かが新しい契約を提案するときは、「まず Liquid で試してみてはどうでしょうか?」と尋ねる価値があります。
これは、ゲストの投稿です ランディ・ナール。 表明された意見は完全に独自のものであり、必ずしもBTCIncまたはの意見を反映しているわけではありません。 Bitcoin マガジン。
元のソース： Bitcoin アフリカ⇔日本 情報雑誌発行