jakiro
著者：Chakra;
この記事は、チャクラが発行したビットコイン拡張シリーズによって公開されたパートIIIです。
最初の部分は前の記事を参照しています」>ビットコインネイティブ拡張スキームレビュー：segwit and taproot“、、、
2番目の部分は、前の記事を参照しています」>ビットコインのスケーラビリティ：Layer2ソリューションと関連するプロジェクト分析“” “。
3番目の部分は、次のようにこの記事です。
概要
Ethereumなどの包括的なブロックチェーンと比較して、ビットコインスクリプトは非常に限られていると考えられており、基本操作のみを実行でき、乗算や除去さえサポートしていません。さらに重要なことは、ブロックチェーン自体のデータにはスクリプトによってほとんどアクセスできず、柔軟性とプログラミングの深刻な欠陥が生じることです。したがって、人々はビットコインスクリプトに内省を実現させるために一生懸命働いてきました。
内部州は、ビットコインスクリプト検査と抑制トランザクションデータの能力を指します。これにより、スクリプトは特定のトランザクションの詳細に基づいてファンドの使用を制御して、より複雑な機能を実現できます。現在、ほとんどのビットコイン操作コードは、ユーザーが提供するデータをスタックにプッシュするか、スタック上の既存のデータを操作します。ただし、内部操作コードは、現在のトランザクションデータ（タイムスタンプ、金額、TXIDなど）をスタックにプッシュできるため、UTXOの支出をより細かく制御できます。
現在、州をサポートするためにビットコインスクリプトには3つの主要な動作コードしかありません。CheckLockTimeVerify、Check Secoseverify、Checkksig、およびそのバリアントはCheckSigverify、CheckSigAdd、CheckMultisig、およびCheckMultiです。
契約（契約は「制限」として翻訳することもできます）。これは、金銭的移動法の制限を指し、ユーザーがUTXOの分布方法を指定できるようにします。多くの契約は、州内の地域の操作コードを通じて達成されています。
Bitcoinには現在、CSV（CheckSequenceVerify）とCLTV（CheckLockTimeVerify）の2つの契約があります。これは、ビットコインの拡張ソリューションが州と契約に深刻に依存していることを示しています。
トークンの転送に条件を追加するにはどうすればよいですか？暗号通貨の分野では、最も一般的に使用される方法は、コミットメントを通じて、通常はハッシュを通じて達成することです。転送要件が満たされていることを証明するために、検証するために署名メカニズムも必要です。したがって、契約のハッシュと署名には多くの調整があります。
以下に、広く議論されている契約運用コードの提案について説明します。
CTV（CheckTemplateify）BIP-119
CTV（CheckTemplatingVerify）は、BIP-119のビットコインアップグレード提案であり、コミュニティから広範囲にわたる注目を集めています。CTVを使用すると、出力スクリプトは、Nversion、nlocktime、Scriptsig Hash、入力カウント、シーケンスハッシュ、出力カウント、出力ハッシュ、入力インデックス、その他のフィールドなど、トランザクションのテンプレートを指定できます。これらのテンプレート制限は、ハッシュの約束によって実装されます。スクリプトは、支出トランザクションの指定されたフィールドのハッシュ値が入力スクリプトのハッシュ値と一致するかどうかを確認します。これにより、UTXOの将来のトランザクションの時間、方法、および量が効果的に制限されます。
入力TXIDがこのハッシュから除外されていることは注目に値します。この除外は、従来の隔離証人では、デフォルトのSighash_all署名タイプを使用する場合、TXIDはScriptPubkeyの値に依存するためです。TXIDを含めると、ハッシュコミットメントで循環依存関係を引き起こす可能性があり、構築することはできません。
CTVの内部方法は、HASH操作の指定されたトランザクション情報を直接引き出し、スタックのコミットメントと比較することです。この内部の州には、チェーンスペースには低い要件が必要ですが、特定の柔軟性がありません。
ビットコイン2層ソリューション（Lightning Networkなど）の基礎は、指名されたトランザクションです。事前調整は通常、事前にトランザクションの生成と署名を指しますが、特定の条件を満たす前にそれらを放送することはありません。本質的に、CTVは、より厳格なプレシグイン-NickNameフォームを実装し、チェーンで事前に配置された約束を公開し、事前に定義されたテンプレートに限定します。
CTVはもともと、ビットコインの混雑を軽減するために提案されていましたが、これは混雑制御とも呼ばれます。混雑が深刻な場合、CTVは、1回のトランザクションで複数の将来のトランザクションを約束して、ピーク時の複数のトランザクションを放送しないようにし、混雑が解放された後に実際のトランザクションを完了することができます。これは、交換中に特に役立つ場合があります。さらに、テンプレートを使用して、ハッキングを防ぐためにボールトを実装できます。資金の流れは事前に決定されているため、ハッカーはCTVスクリプトを使用してUTXOを住所に向けることはできません。
CTVは、ネットワークの2番目のレイヤーを大幅に強化できます。たとえば、Lightningネットワークでは、CTVはCTVツリーに単一のUTXOを拡張することで、タイムアウトツリーとチャネル工場を作成できます。さらに、CTVはATLCを介したARKプロトコルの原子トランザクションもサポートしています。
apo（sighash_anyprevout）bip-118
BIP-118は、Sighash_anyprevoutと呼ばれるより柔軟な支出ロジックを促進することを目的とした、新しいタイプの署名ハッシュロゴをTapscriptに導入しました。APOとCTVには多くの類似点があります。ScriptPubkeysとTXIDの間のサイクルを解く場合、APOメソッドは、関連する入力情報を削除し、出力のみに署名して、トランザクションが異なるUTXOに動的にバインドできるようにすることです。
論理的には、署名検証操作op_checksig（およびそのバリアント）が3つの関数を実行します。
1。議会支出取引の各部分。
2。彼らのためのハック。
3.ハッシュが特定のキーによって署名されているかどうかを確認します。
署名の特定の詳細は非常に柔軟であり、Sighashロゴはトランザクションのどのフィールドを決定します。BIP 342の署名操作コードの定義によれば、SighashロゴはSighash_all、Sighash_None、Sighash_single、Sighashonecanpayに分割されています。Sighash_anyonecanPayは入力を制御し、その他の制御出力。
Sighash_allは、すべての出力に署名するデフォルトのSighashロゴです。Sighash_anyonecanpayは、最初の3つのSighashロゴで設定できます。Sighash_anyonecanpayが設定されている場合、指定された入力のみが署名されます。
明らかに、これらのSighashロゴは、Sighash_anyonecanpayであっても、入力の影響を排除することはできません。また、入力を約束する必要があります。
したがって、BIP 118はSighash_anyprevoutを提案しています。APOの署名は、UTXOを入力すること（前と呼ばれる）を入力することを約束する必要はありませんが、ビットコイン制御の柔軟性を高めるために出力に署名するだけです。トランザクションを事前に構築し、対応する1つの署名と公開キーを作成することにより、公開鍵アドレスに送信された資産は、事前に構築されたトランザクションで使用して契約を達成する必要があります。APOの柔軟性は、トランザクションの修理にも使用できます。さらに、複数の署名ウォレットの場合、使用された入力に依存しないと、操作がより便利になります。
ScriptPubkeysと入力TXIDの間のサイクルを排除するため、APOは目撃者に出力データを追加することで内部の州を実行できますが、これには追加の証人スペース消費が必要です。
Lightning NetworksやVaults（Vaults）などの並べ替えの場合、APOは中間状態を維持する必要性を削減し、ストレージの要件と複雑さを大幅に削減します。APOの最も直接的なユースケースは、チャネル工場を簡素化し、軽量で安価な観測タワーを構築し、多くの面でLightningネットワークのパフォーマンスを向上させることなく、一方的な出口を可能にします。APOはCTV関数をシミュレートするためにも使用できますが、個人はCTVよりも高価で効率的な署名およびシグネチャトランザクションを保存する必要があります。
APOの主な批判は、新しいキーバージョンを必要とすることであり、これは単純な後方互換性では達成できません。さらに、新しい署名ハッシュタイプは、二重支払いの潜在的なリスクをもたらす可能性があります。幅広いコミュニティディスカッションの後、APOは、セキュリティの懸念を軽減するために、元の署名メカニズムに従来の署名を追加し、BIP-118コードを取得しました。
OP_VAULT BIP-345
BIP-345は、2つの新しい操作コード、OP_VAULTとOP_VAULT_RECOVERを追加することを提案しています。この遅延中、回復パスの前にトランザクションが実行されました。
ユーザーは、特定のTapRootアドレスを作成することでVaultを作成できます。このアドレスは、MASTに少なくとも2つのスクリプトを含める必要があります。完了前にいつでもトークンを復元できます。
OP_VAULTは、中断された時間をどのように実装します – 撤退の撤退をロックしますか？OP_VAULTは、指定されたスクリプトで使用されているOP_VAULTスクリプトを置き換えて実装され、マストの単一の葉を効果的に更新しながら、残りのTapRootリーフノードを変更せずに維持します。この設計はTLUVに似ていますが、OP_VAULTは内部キーの更新をサポートしていません。
スクリプトの更新中にテンプレートを導入することにより、支払いを制限できます。時間ロック数は、op_vaultで指定されています。
bip-345は、op_vaultとop_vault_recoverを使用して、安全なホスティング方法（紙のウォレットや分散型複数のシグネチャなど）を使用し、同時に設定されます。定期的な支払いの特定の遅延。ユーザーのデバイスは、偶発的な転送が発生した場合、ユーザーは回復を開始できます。
特にトランザクションの回復のために、BIP-345を介してVaultを実装するには、コストの問題が必要です。可能なソリューションには、CPFP（サブノードは親ノードによって支払われます）、一時的なアンカーポイント、新しいSighash_Group Signature Hash Logoが含まれます。
tluv（tapleafupdateverify）
TLUVスキームは、UTXO出口を共有する問題を効果的に解決することを目的としたTaprootを中心に構築されています。ガイダンスの原則は、TAPROOT出力を使用すると、TLUVスクリプトに記載されているように、暗号化された変換とTaprootアドレスの内部構造によって内部キーとマスト（Tapscript Trie）を部分的に更新できることです。これにより、契約機能の実装が可能になります。
TLUVスキームの概念は、新しいオペレーティングコードtapleaf_update_verifyを導入して、新しいTapRootアドレスを作成することです。これは、以下または複数の操作を実行することで実装できます。
-
内部キーを更新します
-
剪定マークルパス
-
現在実行されているスクリプトを削除します
-
マークルパスの終わりに新しいステップを追加する
具体的には、TLUVは3つの入力を受け入れます。
-
内部公開キーを更新する方法を指定します。
-
マークルパスの新しいステップを指定します。
-
現在のスクリプトを削除したり、マークルパスをトリミングするためのステップ数を指定します。
TLUVオペレーティングコードは、更新されたScriptPubkeyを計算し、現在の入力に対応する出力がこのScriptPubkeyに使用されているかどうかを検証します。
Tluvのインスピレーションは、Coinpoolの概念から来ています。現在、ユナイテッドのファンドプールは、作成する前の署名トランザクションに署名するだけですが、ライセンスなしで終了する場合は、二重の署名署名を作成する必要があります。TLUVでは、ライセンスされた許可なしに出口を許可します。たとえば、グループパートナーはTapRootを使用して共有UTXOを構築して資金をまとめることができます。Taprootキーを使用して内部的に資金を譲渡することも、共同で署名して外部で支払いを開始することもできます。個人は、支払いパスを削除するためにいつでも共有基金プールから撤退することができ、他の人は元のパスを介して支払いを完了することができます。また、個人の出口は、内部の他の人に関する他の情報を公開しません。非プーリングトランザクションと比較して、このモデルはより効率的でプライベートです。
TLUVオペレーティングコードは、元のTaproot Trieを更新することにより、支出の制限を実装していますが、出力額の自己侵入を実現していません。したがって、新しい操作コードin_out_amountが必要です。この操作コードは、2つの項目をスタックにプッシュします：UTXO量とこの入力の対応する出力量、そしてTLUVを使用する人々は、数学的コンピューティングシンボルを使用して、更新されたScriptPubkeyに資金が適切に保持されているかどうかを確認する必要があります。
出力量のある内部の州は、最大51桁で表現する必要があるため、複雑さが複雑になりますが、スクリプトでは32桁の数学操作のみを許可します。これには、スクリプトにオペレーターをアップグレードするか、size_groupを使用してin_out_amountを置き換えるために、オペレーティングコードの動作を再定義する必要があります。
TLUVには、地方分権の2階の解決策になる可能性がありますが、Taproot Trieの調整の信頼性を確認する必要があります。
マット
Matt（Merkleize All the Thing）は、3つの目標を達成することを目指しています。状態をMerkleizing、スクリプトのメルクライジング、パフォーマンスのメルクライズ、一般的なスマートコントラクトを達成することです。
-
マークライジング状態：これには、各葉のノードが状態のハッシュ値を表し、マークルルートは契約の全体的な状態を反映するマークルトリーの構築が含まれます。
-
スクリプトのメルクライジング：これは、各葉のノードが可能な状態変換パスを表すマストを形成するためのTapscriptの使用を指します。
-
マークライジングパフォーマンス：マークライズは、暗号化されたコミットメントと詐欺チャレンジメカニズムを通じて実行されます。計算関数の場合、参加者はチェーンの下で計算し、コミットメントf（x）= yをポストします。他の参加者がエラー結果f（x）= zを見つけた場合、チャレンジを起動できます。仲裁は、楽観的なロールアップの原則と同様に、2点検索によって実行されます。
メルケルの実行
マットを達成するために、ビットコインスクリプト言語には次の機能を持つ必要があります。
-
必須の出力には特定のスクリプト（およびその数）があります
-
データを出力に添付します
-
現在の入力（または別の入力）からデータを読む
2番目のポイントは重要です。動的データは、Analog State Machineが次の状態と追加データを決定できるため、消費者が提供する入力データを通じて状態を計算できることを意味します。MATTスキームは、op_checontractverify（op_ccv）操作コードを介して実装されています。
コントロール量：最も直接的な方法は、直接的な県です。ただし、出力量は64桁で、64ビット算術が必要であり、ビットコインスクリプトに大きな複雑さがあります。OP_CCVは、OP_VAULTなどの遅延チェック法を使用します。CCVのすべての入力出力の入力量は、出力量の下限として追加されます。遅延は、このテストがトランザクション中に発生し、スクリプト評価入力ではなく発生するためです。
詐欺証明の普遍性を考慮して、Matt契約のいくつかのバリエーションは、あらゆる種類のスマート契約または2層の構造を達成できるはずですが、追加の要件が必要です（キャピタルロックやチャレンジの遅延など）トランザクション。たとえば、暗号化されたコミットメントと詐欺チャレンジメカニズムを使用して、op_zk_verify関数をシミュレートし、ビットコインを信頼せずにロールアップを実現します。
実際には、事態は起こりました。Johan Toras Halsethは、Matt Soft Forkの提案のOP_CheckContractractractractractractractractractractractractractractractractractractractractractractractractractractractaryを使用してElftraceを達成します。契約は、橋がビットコインネイティブ検証によって受信されるようにします。
csfs（op_checksigfromstack）
APO運用コードの導入から、OP_CHECKSIG（およびその関連操作）がトランザクション、ハッシュコンピューティング、検証署名の組み立てを担当することを学びました。ただし、これらの運用検証メッセージは、操作コードによってシリアル化されていることで取引されており、他のメッセージを指定することは許可されていません。簡単に言えば、OP_CHECKSIG（およびその関連操作）の役割は、トランザクションとしてUTXOが署名所有者によって使用されているかどうかを検証することです。
名前が示すように、CSFはスタックから署名を確認することです。CSFS動作コードは、スタックから3つのパラメーターを受信し、署名、メッセージ、公開キーの3つのパラメーターを受け取り、署名の有効性を確認します。これは、人々がスタックにあらゆるニュースを伝え、CSFSを介して検証してビットコインの革新を達成できることを意味します。
CSFSの柔軟性により、支払い署名、承認委員会、予言契約契約、二重支払い保護保証、より重要なトランザクション自己積極的な侵入などのメカニズムを実現できます。トランザクションにCSFSを使用するという原則は非常に簡単です。OP_CHECKSIGで使用されているトランザクションコンテンツが目撃者によってスタックにプッシュされ、同じ公開キーと署名を使用してOP_CSFSとOP_CHECKSIGを検証し、両方の検証が正常に渡された場合、 OP_CSFSのメッセージコンテンツは、OP_CHECKSIG HIDDEN使用のシリアル化された支出トランザクション（他のデータとして）と同じです。次に、スタック上の検証済みのトランザクションデータを取得します。これは、他の操作コードを使用して支出トランザクションを制限するために使用できます。
OP_CATは、さまざまなトランザクションフィールドに接続してシリアル化を完了するため、州が必要とするトランザクションフィールドをより正確に選択できるため、CSFSがOP_CATで表示されることがよくあります。OP_CATがなければ、スクリプトは別々にチェックできるデータから再計算することはできません。
CSFSは、CLTV、CSV、CTV、APOなどのオペレーティングコードを実装して、多機能保存オペレーティングコードにすることができます。したがって、ビットコイン2のスケーラビリティソリューションにも役立ちます。欠点は、署名トランザクションの完全なコピーをスタックに追加する必要があることです。これにより、CSFSを使用してトランザクションのサイズが大幅に増加する可能性があります。対照的に、CLTVやCSVのような単一の目的での保存動作コードの保存オーバーヘッドは非常に少ないですが、新しい特別な内部の各地方操作コードを追加するにはコンセンサスを変更する必要があります。
txhash（op_txhash）
OP_TXHASHは、オペレーターが特定のフィールドを選択してスタックにプッシュできるようにする単純な内部の地方操作コードです。具体的には、op_txhashはスタックからtxhashロゴをポップアップし、txhashを計算（ラベル）txhash、次に生成されたハッシュをスタックに戻します。
TxhashとCTVの類似性のため、コミュニティでの多数の議論が2つで多数の議論をしています。
Txhashは、より高度な取引テンプレートを提供するCTVの一般的なアップグレードと見なすことができます。他の契約コードとは異なり、TXHASHはテストで必要なデータを目撃する必要はありませんCTVおよびAPOSとして使用されます。
契約を構築するという観点から、TXHASHは「追加の契約」を作成するためにより多くのものです。固定値と固定値の一致。次に、ローリングSHA256操作コードを使用します。自由はこの中間国家に行動しています。
TXHASH仕様で定義されているTXFieldSelectorフィールドは、OP_TXなどの他の動作コードに拡張されると予想されます。
Txhashに関連するBIPは現在GitHubのドラフトにあり、まだ分布していません。
op_cat
OP_CATは、セキュリティ上の考慮事項のために元々中本によって放棄された神秘的な操作コードですが、最近、ビットコインのコア開発者の間で激しい議論を引き起こし、インターネット上でミーム文化を引き起こしました。最終的に、OP_CATはBIP-347で承認されました。これは、最近最も可能性の高いBIP提案と呼ばれています。
実際、OP_CATの動作は非常に単純です。スタックから2つの要素を接続します。契約機能をどのように実装しますか？
実際、2つの要素を接続する機能は、強力な暗号化されたデータ構造、Merkle Trieに対応しています。Merkle Trieを構築するには、接続とハッシュ操作のみが必要であり、ビットコインスクリプトはハッシュ関数を提供します。したがって、OP_CATを使用すると、理論的にはMerkleを検証して、これがブロックチェーンテクノロジーで最も一般的な軽量検証方法の1つであることを証明できます。
前述のように、CSFはOP_CATの助けを借りて共通の契約ソリューションを実現できます。実際、たとえCSFがない場合でも、OP_CAT自体は、Schnorrが署名した構造を使用して取引局を実現できます。
Schnorrの署名では、署名する必要があるメッセージは、次のフィールドで構成されています。
これらのフィールドには、トランザクションの主な要素が含まれます。それらをScriptPubkeyまたはWitnessに配置し、OP_CATバインディングOP_SHA256を使用することにより、Schnorrの署名を構築し、OP_CHECKSIGを使用して確認することができます。検証が渡された場合、スタックは検証済みのトランザクションデータを保持して、内省からのトランザクションを達成します。これにより、入力、出力、ターゲットアドレス、またはビットコインなど、各部品を抽出および「チェック」できます。
特定のパスワード科学については、Andrew Poelstraの記事「Cat and Schnorr Tricks」を参照できます。
全体として、OP_CATの汎用性により、ほぼすべての契約運用コードをシミュレートできます。多くの契約作戦コードは、OP_CATの機能に依存しており、合併表での位置を大幅に改善しています。理論的には、OP_CATと既存のビットコイン運用コードに依存して、信頼できるBTC ZKロールアップを構築したいと考えています。Starknet、Chakra、およびその他のエコシステムパートナーは、この目標の実現を積極的に促進しています。
結論は
ビットコインの拡大とそのプログラムの強化のさまざまな戦略を探求するとき、前進する道路には、ネイティブの改善、チェーンの計算、複雑なスクリプト機能の融合が含まれることは明らかです。
柔軟な基本レイヤーがない場合、より柔軟な2層を構築することは不可能です。
チェーンの下での計算拡張は将来の傾向ですが、ビットコインのプログラミングには、このスケーラビリティをよりよくサポートし、真のグローバル通貨になるためにブレークスルーが必要です。
ただし、ビットコインのコンピューティングの性質は、イーサリアムのコンピューティングの性質と根本的に異なります。ビットコインは、コンピューティングフォームとしての「検証」のみをサポートし、一般的なコンピューティングを実行することはできません。1つの時点から見ることができます。イーサリアムは不当な取引にガス料金を請求しますが、ビットコインは請求されません。
契約は、コンピューティングではなく検証に基づくスマート契約です。いくつかの中本財務省に加えて、誰もがビットコインを改善するのに適した選択だと誰もが考えているようです。ただし、コミュニティは、どの方法を契約の実装に使用すべきかを依然として激しく議論しています。
APO、OP_VAULT、およびTLUVは、これらの3つの方法を選択することができ、特定のアプリケーションを効率的に実現できます。Lightning Network愛好家は、ln音楽を達成するためにAPOを選択します。OP_CATとTXHASHはより豊富であり、セキュリティの脆弱性の可能性は他の操作コードと組み合わせることができますが、コストが増加する可能性があります。CTVとCSFはブロックチェーン処理方法を調整し、CTVは遅延出力を実装し、CSFSは遅延署名を実現します。Mattは、楽観的な実行と詐欺の戦略で際立っており、Merkle Trie構造を使用して一般的なスマートコントラクトを達成しますが、州の機能には新しい動作コードが必要です。
ビットコインコミュニティは、ソフトフォークを介して契約を取得する可能性について積極的に議論していることがわかります。Starknetは、Bitcoinエコシステムの追加を正式に発表し、OP_CATの合併後6か月以内にビットコインネットワークで決済を達成する計画を立てています。Chakraは、ビットコインエコシステムの最新の開発に引き続き注意を払い、OP_CATソフトフォークの合併を促進し、契約のプログラマティック構造を使用して、より安全で効率的なビットコイン決済層を構築します。
