ログイン/ 登録

ビットコインのプログラマビリティ・スキーム「イントロスペクション」と「コヴェナント」の説明

JinseFinance

2024/07/15 19:41

従う

著者：Chakra; Compiled by 0xjs@GoldenFinance

この記事は、Chakraが発表したビットコインのスケーラビリティに関する一連の記事の第3部です。

第1部は、Golden Financeの前回の記事「Review of Bitcoin's Native Scaling Schemes: SegWit and Taproot」を参照し、

第二部はゴールデンファイナンスの前回の記事「ビットコインのスケーラビリティ：Layer2スキームと関連プロジェクトの分析」を参照しています。

この記事の第3部は以下の通りです：

概要

イーサのようなチューリング完全ブロックチェーンと比べると、ビットコインのスクリプトは非常に制限的で、基本的な算術しかできず、掛け算や割り算さえサポートしていないと考えられています。さらに、ブロックチェーン自身のデータはスクリプトから事実上アクセスできないため、柔軟性やプログラム性が著しく欠如している。その結果、ビットコインのスクリプトでイントロスペクションを可能にする取り組みが行われてきました。

イントロスペクションとは、ビットコインスクリプトがトランザクションデータを検査し、制約する能力のことです。これにより、スクリプトは特定のトランザクションの詳細に基づいて資金の使用を制御できるようになり、より複雑な機能が可能になります。現在、ほとんどのビットコインのオペコードは、ユーザーが提供したデータをスタックにプッシュするか、スタック上の既存のデータを操作する。しかし、イントロスペクションオプコードは、現在のトランザクションからのデータ（タイムスタンプ、金額、txidなど）をスタックにプッシュすることができ、UTXOの支出をより詳細に制御することができます。

現在のところ、イントロスペクションをサポートするビットコインスクリプトの主要なオペコードは、CHECKLOCKTIMEVERIFY、CHECKSEQUENCEVERIFY、CHECKSIG、およびそれらの亜種であるCHECKSIGVERIFY、CHECKSIGADD、CHECKMULTISIG、CHECKMULTISIGVERIFY、CHECKMULTISIGADD、CHECKMULTISIGADD、CHECKMULTISIGADDの3つだけです。CHECKMULTISIGVERIFY.

制約としても知られるコベナンツは、UTXOがどのように割り当てられるべきかをユーザが指定できるようにする、送金方法に関する単純な制約です。多くのコベナントはイントロスペクションオプコードを通して実装されており、イントロスペクションの議論は現在、ビットコインオプテックコベナントトピックに分類されています。

ビットコインには現在、CSV（CheckSequenceVerify）とCLTV（CheckLockTimeVerify）という2つの契約があり、どちらもライトニングネットワークなどの多くのスケーリングソリューションの基礎となっている時間ベースの契約です。これは、ビットコインのスケーリングソリューションがイントロスペクションとコントラクトに大きく依存していることを示しています。

トークンの移転にどのように条件を加えるのか？暗号通貨の領域では、これを行う最も一般的な方法は、通常ハッシュを介した約束です。送金条件が満たされたことを証明するためには、検証のための署名メカニズムも必要です。その結果、契約ではハッシュと署名の調整が多く行われます。

以下では、広く議論されているCovenant opcode案について説明します。

CTV（CheckTemplateVerify）BIP-119

CTV（CheckTemplateVerify）はBIP-119におけるビットコインのアップグレード提案であり、コミュニティから多くの注目を集めています。CTVでは、出力スクリプトが、nVersion、nLockTime、scriptSigハッシュ、入力カウント、シーケンスハッシュ、出力カウント、出力ハッシュ、および入力インデックスなどのフィールドを含む、取引における資金支出のテンプレートを指定することができます。これらのテンプレート制限は、ハッシュの約束を通じて実装され、資金が使用されると、スクリプトは、支出トランザクションの指定されたフィールドのハッシュ値が入力スクリプトのハッシュ値と一致するかどうかをチェックする。これにより、そのUTXOの将来のトランザクションの時間、方法、量が効果的に制限される。

このハッシュから入力TXIDが除外されていることは注目に値します。この除外が必要なのは、従来の証人と分離された証人の両方のトランザクションにおいて、デフォルトのSIGHASH_ALL署名タイプを使用する場合、TXIDはscriptPubKeyの値に依存するからです。TXIDを含めると、ハッシュのコミットメントに循環的な依存関係が生じ、構築できなくなります。

CTVの内省的アプローチは、ハッシュ化のために指定されたトランザクション情報を直接引き出し、それをスタック上のコミットメントと比較することです。この内省的アプローチは、より少ないチェーンスペースを必要としますが、いくつかの柔軟性に欠けています。

ライトニングネットワークなどのビットコインの第2層ソリューションの基盤は、事前署名トランザクションです。事前署名は通常、トランザクションを事前に生成して署名しますが、特定の条件が満たされるまでそれをブロードキャストしません。基本的に、CTVは事前署名された約束をチェーン上に公開し、事前定義されたテンプレートに制限することで、より厳格な事前署名を実装しています。

CTVはもともと、ビットコインの混雑を緩和するために提案されました。輻輳が激しい時間帯に、CTVは単一のトランザクションで複数の将来のトランザクションをコミットし、ピーク時間帯に複数のトランザクションをブロードキャストすることを回避し、輻輳が緩和された時点で実際のトランザクションを完了することができます。これは、特に取引所運営時に有用であろう。さらに、テンプレートはハッキングを防止するためのVaultを実装するために使用することができる。資金の流れがあらかじめ決まっているため、ハッカーはCTVスクリプトを使ってUTXOを自分のアドレスに向けることができません。

CTVはレイヤー2ネットワークを大幅に強化することができます。例えば、ライトニングネットワークにおいて、CTVは1つのUTXOをCTVツリーに拡張することで、タイムアウトツリーやチャネルファクトリを作成し、1つのトランザクションと1つの確認で複数のステートチャネルを開くことができます。さらに、CTVはATLCを通じてArkプロトコルのアトミックトランザクションをサポートする。

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 は、SIGHASH_ANYPREVOUT と呼ばれる、より柔軟な支出ロジックを促進するように設計された、新しいタイプの署名付きハッシュフラグをタップスクリプトに導入します。 APOとCTVには多くの類似点があります。scriptPubKeyとTXID間のループを解決する上で、APOのアプローチは、関連する入力情報を除外し、出力のみに署名することで、トランザクションを異なるUTXOに動的にバインドすることを可能にします。

論理的には、署名検証操作OP_CHECKSIG（およびその亜種）は次の3つの機能を実行します、支出トランザクションのパーツを組み立てる。

2、それらをハッシュ化します。

3、ハッシュが与えられたキーによって署名されたことを検証する。

トランザクションのどのフィールドが署名されるかはSIGHASHフラグによって決定される。SIGHASHフラグは、BIP 342の署名オペランドの定義に従って、SIGHASH_ALL、SIGHASH_NONE、SIGHASH_SINGLE、SIGHASH_ANYONECANPAYに分類される。

SIGHASH_ALLはデフォルトのSIGHASHフラグで、すべての出力に署名します。SIGHASH_NONEはどの出力にも署名せず、SIGHASH_SINGLEは特定の出力に署名します。SIGHASH_ANYONECANPAYが設定された場合、指定された入力のみが署名され、そうでない場合は、すべての入力が署名されなければなりません。

明らかに、これらのSIGHASHフラグは入力の影響を排除するものではなく、SIGHASH_ANYONECANPAYであっても、入力のコミットメントを必要とします。

そのため、BIP 118はSIGHASH_ANYPREVOUTを提案しています。（PREVOUTとして知られる）費やされた入力UTXOにコミットする代わりに、APO署名は単に出力に署名し、ビットコイン制御におけるより大きな柔軟性を提供します。APOの柔軟性はトランザクションの修復にも利用できる。低手数料のためにトランザクションがチェーン内で立ち往生した場合、新たな署名を必要とせずに手数料を増やすために別のトランザクションを簡単に作成できる。さらに、マルチシグネチャーのウォレットでは、すでに使われた入力に依存しないため、運用が容易になります。

scriptPubKeyと入力TXID間のループがなくなるため、APOは出力データをウィットネスに追加することでイントロスペクションを実行できますが、これはまだ追加のウィットネススペース消費を必要とします。

ライトニングネットワークやボールトのようなオフチェーンプロトコルでは、APOは中間状態を保存する必要性を減らし、ストレージ要件と複雑さを大幅に削減します。APOの最も直接的な使用例はEltooで、チャネルファクトリを簡素化し、軽量で安価なウォッチタワーを構築し、エラー状態を残すことなく一方的に終了できるようにすることで、多くの点でライトニングネットワークを強化します。APOはCTVの機能をエミュレートするために使用することもできますが、署名と署名済みトランザクションを個人的に保存する必要があり、CTVよりも高価で効率的ではありません。

APOの主な批判は、単純な後方互換性では実現できない、新しいバージョンの鍵を必要とするという事実に集中している。さらに、新しい署名ハッシュタイプは、二重支払いの潜在的なリスクをもたらす可能性があります。コミュニティでの広範な議論の後、APOはセキュリティ上の懸念を軽減するために、オリジナルの署名メカニズムに加えて通常の署名を追加し、その結果BIP-118コードが誕生した。

OP_VAULT BIP-345

BIP-345 は、OP_VAULTとOP_VAULT_RECOVERという2つの新しいオペコードの追加を提案しており、CTVと組み合わせて使用することで、ユーザーが特定の通貨の使用を遅延させることを可能にする特別な契約を可能にします。この遅延の間、以前に行われた取引はリカバリーパスを介して「取り消す」ことができます。

ユーザーは、MASTに少なくとも2つのスクリプトを含む必要がある特定のTaprootアドレスを作成することで、Vaultを作成することができます。1つはOP_VAULTオペコードで、意図した引き出しプロセスを容易にし、もう1つはOP_VAULT_RECOVERオペコードで、引き出しが完了する前にいつでもトークンを復元できるようにします。

スクリプトの更新中にテンプレートを導入することで、支払いを制限することができます。時間ロックパラメーターはOP_VAULTによって指定され、CTVオペコードのテンプレートは、このスクリプトパスを通して使用できる出力のセットを制限します。

ボールト用に設計されたBIP-345は、OP_VAULTおよびOP_VAULT_RECOVERを活用して、定期的な支払いに一定の待ち時間を設定しながら、回復パスとして高度に安全なキー（ペーパーウォレットや分散マルチ署名など）を使用する安全なエスクロー方法をユーザーに提供します。ユーザーのデバイスは継続的に保管庫の支出を監視し、予期せぬ送金が発生した場合にユーザーがリカバリーを開始できるようにします。

BIP-345を介してVaultを実装するには、特にリカバリトランザクションのコストを考慮する必要があります。考えられる解決策としては、CPFP（子ノードが親ノードのために支払う）、一時的なアンカー、新しいSIGHASH_GROUP署名ハッシュフラグなどがあります。

TLUV (TapleafUpdateVerify)

TLUVソリューションはTaprootを中心に構築されており、共有されたUTXOの出口に効率的に対処するように設計されています。指針となる原則は、TLUVスクリプトで説明されているように、Taproot出力が使用されるときに、暗号変換とTaprootアドレスの内部構造を通して、内部キーとMAST（tapscript trie）を部分的に更新できることです。これにより、Covenant機能が可能になります。

TLUVスキームのコンセプトは、新しいオペコードTAPLEAF_UPDATE_VERIFYを導入することによって、現在の費用入力に基づいて新しいTaprootアドレスを作成することです。

Update internal public key
Trim Merkle path
Delete the current executing script
Merkleパスの最後に新しいステップを追加する

具体的には、TLUVは3種類の入力を受け付けます:

内部公開鍵の更新方法を指定します。
メルクルパスの新しいステップを指定する1つの方法を指定する。
現在のスクリプトを削除するかどうか、および/または、Merkleパスのいくつのステップを削除するかを指定する。

TLUVオペコードは、更新されたscriptPubKeyを計算し、現在の入力に対応する出力がこのscriptPubKeyに費やされていることを検証する。

TLUVはCoinPoolの概念に触発されました。今日、CoinPoolは事前に署名されたトランザクションのみで作成できますが、パーミッションレスで終了できるようにするには、指数関数的に増加する署名を作成する必要があります。一方TLUVは、事前署名なしでパーミッションレスな退出を可能にする。例えば、パートナーのグループは、Taprootを使って共有UTXOを構築し、資金をプールすることができる。彼らはTaprootキーを使って内部的に資金を移動したり、共同署名して外部への支払いを開始したりできる。個人はいつでも共有プールから抜けることができ、自分の支払い経路を削除する一方で、他の人は元の経路で支払いを完了することができる。このモデルは、プールされていないトランザクションよりも効率的でプライベートです。

TLUVオペコードは、オリジナルのTaproot Trieを更新することで、支出制限の一部を実装しているが、出力金額のイントロスペクションを実装していない。したがって、IN_OUT_AMOUNTという新しいオペコードも必要である。このオペコードは、2つの項目をスタックにプッシュする。すなわち、この入力に対するUTXOの金額と、出力に対する対応する金額である。それから、TLUVを使用する者は、資金が更新されたscriptPubKeyに適切に保持されていることを検証するために数学演算子を使用する必要がある。

出力金額のイントロスペクションは、サトシの金額を表現するために最大51ビットを必要とするが、スクリプトでは32ビットの計算しかできないため、複雑さが増す。

TLUVは分散型レイヤー2プーリングのソリューションとなる可能性を秘めていますが、Taproot Trieのチューニングの信頼性はまだ確認する必要があります。

MATT

MATT (Merkleize All The Things)は3つの目標を達成することを目指している。コントラクトにつながる。

Merkleizing the state: これは、各リーフノードが状態のハッシュを表し、Merkle Rootがコントラクトの全体的な状態を表す、Merkle Trieを構築することを含みます。
スクリプトのメルクル化：これはTapscriptを使用してMASTを形成することを指し、各リーフノードは可能な状態遷移パスを表します。
実行をメルクル化する：暗号化された約束と不正チャレンジメカニズムによって実行をメルクル化する。他の参加者が不正な結果f(x)=zを見つけた場合、チャレンジを開始することができる。裁定は、Optimistic Rollupの原理と同様に、バイナリサーチによって行われる。

マーセライズ実行

MATTを実装するためには、ビットコインスクリプト言語は以下の機能を持つ必要があります:

出力に特定のスクリプト（およびその番号）を強制する

出力にデータの一部を追加する

現在の入力（または別の入力）からデータを読み取る

2つ目のポイントは非常に重要です。MATTスキームは、OP_CHECKCONTRACTVERIFY（OP_CCV）オペコードによってこれを実現します。CHECKOUTPUTCONTRACTVERIFYオペコードとOP_CHECKINPUTCONTRACTVERIFYオペコードを組み合わせたもので、追加のフラグ・パラメータを使用して操作のターゲットを指定します。

出力量の制御：最も簡単な方法は、直接イントロスペクションです。しかし、出力量は64ビット数値であり、64ビット演算を必要とするため、ビットコインスクリプトに大きな複雑さをもたらします。OP_CCVは、OP_VAULTのような遅延チェック方法を使用します。CCV内の同じ出力に対するすべての入力の入力量が合計され、その出力量の下界として機能します。遅延は、このチェックが入力を評価するスクリプトの間ではなく、トランザクションの間に発生するという事実によるものです。

不正証明のユビキタス性を考えると、MATTコントラクトのいくつかのバリエーションは、あらゆるタイプのスマートコントラクトやレイヤー2コンストラクトに実装できるはずですが、追加の要件（例えば、ファンドロックやチャレンジ期間の遅延）を正確に評価する必要があります。例えば、OP_ZK_VERIFY関数をエミュレートするために暗号化約束と詐欺チャレンジメカニズムを使用して、Bitcoin上でトラストレスロールアップを実装することです。

現実的には、それはすでに起こっています。Johan Torås Halseth氏は、MATTソフトフォーク提案のOP_CHECKCONTRACTVERIFYオペコードを使用してelftraceを実装しました。elftraceは、RISC-Vコンパイルをサポートする任意のプログラムがビットコインのブロックチェーン上で検証できるようにするもので、契約上の合意の一方の当事者が契約検証を介して資金にアクセスできるようにすることで、ビットコインのネイティブ検証への橋渡しをします。

CSFS (OP_CHECKSIGFROMSTACK)

APOオペコードの紹介から、OP_CHECKSIG（およびそれに関連する演算）がトランザクションのアセンブル、ハッシュ計算、署名の検証を担っていることを理解しました。しかし、これらの操作によって検証されるメッセージは、オペコードを通じてトランザクションを直列化することから来るものであり、他のメッセージを指定することはできない。要するに、OP_CHECKSIG（およびそれに関連する操作）は、トランザクションの入力として費やされたUTXOが署名保持者によって使用が承認されていることを検証するために署名メカニズムを使用することによって、ビットコインを安全にする役割を果たす。

CSFSの柔軟性により、支払い署名、委任、述語契約、二重支払い保護保証、さらに重要なこととして、トランザクションのイントロスペクションなどのメカニズムを実装することができます。OP_CHECKSIGによって使用されるトランザクションのコンテンツが、証人を介してスタックにプッシュされ、同じ公開鍵と署名を使用してOP_CSFSとOP_CHECKSIGに対して検証され、両方の検証に成功した場合、OP_CSFSに渡されるメッセージのコンテンツは、OP_CHECKSIGによって暗黙的に使用されるメッセージのコンテンツと同じです。CHECKSIGは暗黙的に、同じシリアル化された支出トランザクション（およびその他のデータ）を使用する。そして、他のオペコードを使用する支出トランザクションに制限を課すために使用できる、検証されたトランザクションデータをスタック上で取得する。

CSFSにはOP_CATが付属していることが多いが、これはOP_CATがトランザクションの異なるフィールドを連結してシリアライズを完了できるため、イントロスペクションに必要なトランザクションフィールドをより正確に選択できるからである。OP_CATがない場合、スクリプトは個別に検査できるデータからハッシュを再計算できないため、実際にできることはハッシュが特定の値に対応しているかどうかをチェックすることだけである。

CSFSはCLTV、CSV、CTV、APOなどのオペコードを実装することができ、多目的なイントロスペクションのオペコードとなっています。そのため、ビットコインのレイヤー2のスケーラビリティ・ソリューションにも貢献します。欠点は、署名されたトランザクションの完全なコピーをスタックに追加する必要があり、CSFS を使用してイントロスペクションされるトランザクションのサイズが大幅に増大する可能性があることである。対照的に、CLTVやCSVのような単一目的のイントロスペクション・オプコードはオーバーヘッドが最小であるが、新しい特別なイントロスペクション・オプコードを追加するごとにコンセンサスの変更が必要となる。

TXHASH (OP_TXHASH)

OP_TXHASH は、オペレータが特定のフィールドのハッシュを選択してスタックにプッシュすることを可能にする、単純なイントロスペクションオプコードです。具体的には、OP_TXHASHはスタックからtxhashフラグをポップし、そのフラグに基づいて(ラベル付きの)txhashを計算し、結果のハッシュをスタックにプッシュします。

TXHASHとCTVは類似しているため、コミュニティでは両者について多くの議論が生じています。

TXHASHはCTVの一般的なアップグレードと見なすことができ、より高度なトランザクションテンプレートを提供し、ユーザーが費用トランザクションの一部を明示的に指定することを可能にし、トランザクション手数料に関連する多くの問題を解決します。他のコヴェナント・オプコードとは異なり、TXHASHは必要なデータのコピーを証人に必要としないため、ストレージ要件がさらに削減されます。CTVとは異なり、TXHASHはNOP互換性がなく、タップスクリプトでのみ実装可能です。

契約の観点からは、TXHASHは、修正したいトランザクションデータのすべての部分がスタックにプッシュされ、一緒にハッシュされ、結果のハッシュが修正と一致することが検証される「加算契約」の作成に適しています。CTVは、修正したいトランザクションデータのすべての部分がスタックにプッシュされ、一緒にハッシュされ、結果のハッシュが修正と一致することが検証される「減算契約」の作成に適しています。「減算契約」では、自由にしておきたいトランザクションデータのすべての部分がスタックにプッシュされる。次に、ローリングSHA256オペコードを使用して、トランザクションハッシュデータのプレフィックスにコミットされる固定中間状態からハッシュ処理を開始する。フリー部分はこの中間状態にハッシュされる。

TXHASH仕様で定義されているTxFieldSelectorフィールドは、OP_TXのような他のオペコードにも拡張される予定です。

TXHASHに関連するBIPは、現在GitHubのDraftステータスであり、まだ番号は割り当てられていません。

OP_CAT

OP_CATは謎めいたオペコードで、当初はセキュリティ上の理由からサトシ・ナカモトによって削除されましたが、最近ではビットコイン・コアの開発者たちの間で激しい議論が巻き起こり、ウェブ上でミーム（Meme）文化まで生まれました。最終的に、OP_CATはBIP-347で承認され、最近の記憶では通過する可能性が最も高いBIP提案と言われています。

実際のところ、OP_CATの動作は非常にシンプルです。どのようにしてCovenant機能を実現しているのでしょうか？

前述したように、CSFSはOP_CATの助けを借りて汎用的な規約スキームを可能にします。実際、CSFSがなくても、OP_CAT自体で、Schnorr署名の構造を使用して、トランザクションのイントロスペクションが可能です。

Schnorr署名では、署名されるメッセージは以下のフィールドで構成されます：

これらのフィールドには、トランザクションの主要な要素が含まれています。これらをscriptPubKeyまたはWitnessに配置し、OP_CATをOP_SHA256と組み合わせて使用することで、シュナー署名を構築し、OP_CHECKSIGを使用して検証することができます。検証に合格した場合、スタックは検証されたトランザクションデータを保持するため、トランザクションのイントロスペクションが可能になる。これにより、トランザクションの入力、出力、宛先アドレス、関係するビットコインの量など、トランザクションの様々な部分を抽出して「検査」することができる。

暗号全般に関する詳細は、Andrew Poelstra氏の記事「CATとSchnorr Tricks」を参照してください。

まとめると、OP_CATの多用途性により、ほぼすべてのCovenant opcodeをエミュレートすることができます。多くのCovenantオペコードはOP_CATの機能に依存しており、マージリストにおけるOP_CATの地位を大いに高めています。理論的には、OP_CATと既存のBitcoin opcodeだけに頼れば、信頼を最小化するBTC ZK Rollupの構築が期待でき、Starknet、Chakra、およびその他のエコシステム・パートナーは、これを実現するために積極的に推進しています。

結論

ビットコインを拡張し、そのプログラム可能性を強化するためのさまざまな戦略を探っていくうちに、進むべき道には、ネイティブの改善、オフチェーン計算、複雑なスクリプト機能の融合が必要であることが明らかになりました。

柔軟な基本層なしに、より柔軟な第2層を構築することは不可能です。

オフチェーンでの計算スケーリングは将来的なものですが、ビットコインのプログラマビリティは、そのスケーリングをよりよくサポートし、真にグローバルな通貨になるためのブレークスルーが必要です。

しかし、ビットコインの計算の性質は、イーサのそれとは根本的に異なります。ビットコインは計算の一形態として「検証」のみをサポートし、一般的な計算を実行できないのに対し、イーサは本質的に計算的であり、検証は計算の副産物です。この違いは、イーサが実行できない取引に対してガス料金を請求するのに対し、ビットコインは請求しないという点にも表れています。

契約は、計算ではなく検証に基づくスマートコントラクトの一形態です。一部のサトシ・ナカモト原理主義者を除いて、コントラクトがビットコインを改善するための良い選択肢であることに誰もが同意しているようだ。しかし、コミュニティでは、コントラクトを実装するためにどの方法を使用すべきかについて、まだ激しい議論が続いています。

APO、OP_VAULT、TLUVは直接適用を支持しており、これら3つの方法の選択は、特定のアプリケーションのために実装する方が安価で効率的である可能性があります。ライトニングネットワークの愛好者は、LN-Symmetryを実装するためにAPOを選択するでしょう。Vaultを実装したいユーザーはOP_VAULTを使用する方がよいでしょう。 OP_CATとTXHASHはより機能が豊富で、セキュリティの脆弱性が少なく、他のオペコードと組み合わせることで、より多くのアプリケーションに実装することができます。OP_CATとTXHASHはより機能が豊富で、セキュリティの脆弱性がある可能性が高く、他のオペコードと組み合わせることで、より多くのユースケースを可能にすることができますが、おそらくスクリプトの複雑さが増すという代償を払うことになるでしょう。ctvとcsfsはブロックチェーン処理に適応し、ctvは遅延出力、csfsは遅延署名を可能にします。mattは楽観的な実行と不正防止戦略で際立っており、Merkle Trie構造を活用して汎用スマートコントラクトを可能にしますが、イントロスペクション機能にはまだ新しいオペコードが必要になるでしょう。

私たちは、ビットコインコミュニティがソフトフォークを通じてCovenantsを買収する可能性について活発に議論しているのを見てきました。starknetは、OP_CATの合併から6カ月以内にビットコインネットワークに定着する計画で、ビットコインエコシステムに参加することを正式に発表しました。チャクラは、OP_CATソフトフォークの合併を推進し、Covenantsがビットコインエコシステムにもたらすプログラマビリティを活用するため、ビットコインエコシステムの最新動向を引き続き監視していきます。Chakraは、OP_CATソフトフォークの合併を進め、より安全で効率的なビットコイン決済レイヤーを構築するためにCovenantsがもたらすプログラマビリティを活用しながら、ビットコインエコシステムを監視し続けます。

有益なレポートを通じて仮想通貨業界の幅広い理解を得て、志を同じくする他の著者や読者との詳細な議論に参加してください。拡大している Coinlive コミュニティにぜひご参加ください。https://t.me/CoinliveSG

コメントを追加する

ログインあなたの素晴らしいコメントを残すために…

0 コメント

最も早い

コメントをさらに読み込む