「復活」という記事は、サトシ・ナカモト・オペレーション・コードによって削除されましたOP_CATSoft Fork

Jaleel、BlockBeatsによる元の記事

ビットコインコードベースでは、サトシ・ナカモトによって削除され、長らく歴史に封印されていたオペレーションコード「OP _CAT」が「復活」することもある。

OP_CATオペレーションコードを中心に、ビットコインの非代替性トークンプロジェクトであるTaproot Wizardsは、新シリーズ「Non-fungible Token Quantum Cats」を立ち上げました。 OP_CATという用語は、おなじみの「猫」を指すものではありませんが、 Taproot Wizardは、 猫のイメージを使用して、 Quantum Catsと呼ばれる新しい非代替性トークンをリリースし、 OP_CATが勢いをつけるのを助けるためにミーム文化を使用しています。 関連レディング: “ビットコイン “Quantum Cat”: Without Smart Contract, How to Achieve Dynamic Change of Inscriptions?” (「量子猫」:スマートコントラクトなしで、碑文の動的な変化を実現するには?」

OP_CAT、サトシ・ナカモトがビットコインスクリプト言語から削除したオペレーションコードは、現在、議論のテーブルに戻されており、一部のビットコイン開発者は、このオペレーションコードを「復活」させ、13行のコードのソフトフォークを通じてビットコインスマートコントラクトを実装する道を開きたいと考えています。 ビットコイン開発者によって推進され、猫のミームのイメージに勢いが生まれ、OP_CATに関する熱と議論は新たな高みに達しました。

サトシ・ナカモトが削除した「復活」のオペレーションコード

操作コードは、命令または関数とも呼ばれ、ビットコインスクリプト言語の基本的な構成要素です。 歴史的に、一部の操作コードは、クライアント実装の潜在的な脆弱性に関する懸念から、以前のバージョンのビットコインから削除されており、OP_CAT 操作コードもその 1 つです。

OP_CAT はもともと ビットコイン の公式コマンドセットの一部であり、文字列の結合、2 つの要素を 1 つにスプライシングすることを可能にしました。 ただし、OP_LSHIFTなどのオペレーションコードに重大な脆弱性が見つかったため、BitcoinNodeがクラッシュする可能性があるため、OP_CATオペレーションコードによってスタック要素が指数関数的に増加し、メモリ使用量とスクリプトサイズが指数関数的に増加する可能性があることが懸念されます。

そのため、十分な注意を払って、サトシ・ナカモトは2010年8月15日にOP_CATを削除しました。 これらの削除された操作コードは、多くの場合「無効」と呼ばれますが、プロトコルから完全に削除されているため、ビットコインを使用しているユーザーは操作コードを使用できなくなるため、これは正確ではありません。

2023 年 10 月、ビットコイン Core 開発者の Ethan Heilman 氏と Botanix Labs のプリンシパル ソフトウェア エンジニアである Armin Sabouri 氏は、この議論を新たなレベルに引き上げる「OP_CAT」というタイトルのビットコイン改善提案 (BIP) の草案を共同でリリースしました。

このドラフトはわずか 13 行のコードで構成されており、明確で直感的な機能性を持ち、スタック上で 2 つの値を連結できる新しいタップ操作コードを定義しています。 このコードの実装は、削除された元の OP_CAT に明らかに触発されています。

「復活」の条件が満たされた

サトシ・ナカモトによって削除されたオペレーションコードが開発者によって復元されている理由については、このBIPドラフトの動機付けのセクションで、これは主にメモリ使用量の考慮事項に基づいており、OP_CATはスクリプト構造のメモリ使用量をスクリプト自体のサイズから指数関数的に増加させます。 具体的には、1 バイトの値をスタックにプッシュし、それを OP_DUP オペレーション コードでレプリケートし、OP_CAT オペレーション コードで 40 回連結する単純なスクリプトでは、スタック値が 1 TB を超える大規模なサイズに膨れ上がる可能性があります。

それにもかかわらず、時間の進歩と技術の発展により、この問題はもはや障害ではありません。 TAP のアーキテクチャでは、スタック要素の最大サイズが 520 バイトに厳密に制限されているという明確なルールがあります。 この変更により、OP_CATによって引き起こされる可能性のあるメモリ使用量の問題が効果的に解決され、その「復活」と統合の可能性が提供されます。

したがって、OP_CAT は、主により複雑で強力なスクリプトを構築する上での潜在的な価値のために、再び議論に持ち出され、再利用が検討されています。 さらに、次のような多くの理由と変化が「復活」の条件を満たしています。

1.高度なスマートコントラクトとプロトコルの需要:ビットコインエコシステムが成長するにつれて、より高度で複雑なスマートコントラクトとプロトコルの需要が高まっています。 OP_CATは、スタック上でオブジェクトを組み合わせることができるため、タップの表現力と機能性が向上します。 たとえば、マークルツリーやその他のハッシュデータ構造の構築と評価に使用でき、ツリー署名、ポスト量子ランポート署名、否認防止コントラクト、ボールトなどをサポートします。

2. その他のオンチェーンのサクセスストーリー:ビットコイン CashやSidechain Liquidなどの一部のビットコインフォークは、OP_CATを再び有効にし、それを使用してトークンの作成と管理、支払いチャネル、およびブロックチェーンにデータを埋め込んだり取得したりする方法を実装したりしています。 これは、OP_CATが適切な環境と制限の下で安全かつ効果的に使用できることを示しています。

3. 量子セキュリティの探索:OP_CATなどの演算をLamport署名などの技術と組み合わせることで、量子セキュアなビットコイントランザクションやプロトコルを構築できるという研究結果もあります。 この調査は、ビットコインシステムの将来のセキュリティを向上させる上で潜在的な価値があります。

4.コミュニティとテクノロジーの開発:ビットコインコミュニティとテクノロジーの継続的な発展により、人々は以前の決定を再考し、評価するようになりました。 ビットコインプロトコルと新しいテクノロジーの理解が深まるにつれて、以前は問題がある、または適用できないと考えられていた機能が、新しいコンテキストで安全で有用なユースケースを見つける可能性があります。

ソフトフォーク、話題になりやすい

技術的なレベルでは、OP_CATほど解釈と理解が容易なビットコイン提案は他にほとんどありません。 しかし、OP_CAT操作コードは、操作コードOP_SUCCESS 126のソフトフォークを再定義することでアクティブ化されますが、これは明らかに簡単な作業ではありません。

ビットコインの直近のソフトフォークは、3年前にTaprootがアクティベートされ、Ordinalsの誕生への道を開いたことを思い出してください。

コンセンサスと透明性はビットコインコミュニティから高く評価されており、重要なコードの変更は、ソフトフォークを含め、コミュニティ内で広く議論され、レビューされます。 コードの一部をビットコインのコードベースにマージするには、提案の品質とコミュニティのコンセンサスを保証する厳密で詳細なプロセスを経る必要があります。 このプロセスの主な手順は次のとおりです。

1. 提案書とコードを書く: まず、開発者は詳細な提案書を書く必要があります。 この文書では、提案の動機、技術的な詳細、影響評価、および潜在的な問題や課題を明確に説明する必要があります。

2. コミュニティの議論: コード提案がビットコインコミュニティに提出されると、コミュニティメンバー(開発者、マイナー、投資家、ユーザーを含む)によって議論され、レビューされます。 この段階は、提案の実現可能性を確保し、フィードバックを収集するための鍵となります。

3. 修正と改善: コミュニティからのフィードバックに基づいて、コードの作成者は提案に修正と改善を加える必要があるかもしれません。

4. 投票し、コンセンサスを得る: いくつかの重要な改善(特にビットコインプロトコル自体に関連するもの)には、コミュニティメンバー間の一定レベルのコンセンサスが必要です。 これには通常、マイナーのサポートが含まれ、マイナーはマイニングするブロックに特定のシグナルを含めることで、提案への支持を示す必要があります。

5. コードの実装: コンセンサスに達すると、コードは ビットコイン Core 開発者チームによってレビューされます。 この手順では、コードの品質とセキュリティを確保する必要があります。

6.コードベースにマージする:承認後、コードはビットコインの公式コードベースにマージされます。

7.デプロイとアクティベーション:最後に、マイナーとノードオペレーターが新しいコードをシステムにデプロイする必要があります。 プロトコルレベルの変更の場合、通常、十分な数のネットワーク参加者が新しいバージョンにアップグレードした場合にのみ有効になるアクティベーションしきい値があります。

明らかに、OP_ CAT Soft Forkの実装はまだ非常に初期段階にあり、BIPドラフトが書かれてから4か月も経っておらず、BIP番号はまだ決定されておらず、提案とコードを書く第1段階と、開発者とユーザーが参加するコミュニティの議論の第2段階にあります。

ビットコイン開発者の声

近年のビットコイン開発者の間でのOP_CATの議論に特に注意を払いましょう。

OP_CAT 操作コードは削除されましたが、高度なコントラクトを容易にし、ビットコインスクリプト言語を強化する上での OP_CAT の潜在的な有用性は、開発者の間で繰り返し議論されてきました。 たとえば、スタック値を接続する機能は、OP_CAT がサポートされている場合にトランザクション サイズを大幅に削減できる TumbleBit などの一部のビットコインプロトコルの開発に対する障壁と見なされます。

Optech ニュースレターとさまざまな関連コンテンツを集めたところで、OP_CAT オペレーション コードに関するビットコイン開発者の議論を時系列で整理してみましょう。

2019

OP_CAT ビットコイン Improvement Proposal(BIP)草案のスポンサーの1人であるEthan Heilman氏は、2019年10月の電子メールで、当時のスクリプトが直面していた悲惨な状況のために削除された理由は理解できると述べたが、オペレーションビットコインコードとしてのOP_CATの価値を強調した。 研究者として、もし私がこの制限を経験しているなら、それは他の人の進歩を妨げている可能性があります。 杖を振って無効にしたオペレーションコードの1つを再び有効にできるとしたら、OP_CATを選択します。 もちろん、これには、連結された各値のサイズを 64 バイト以下に制限する必要があるという条件が伴います。 」

OP_CATの議論になると、アンドリュー・ポールストラは決して回避できない人です。 彼は2021年1月30日に「CATとシュノアのトリックI」というタイトルの記事を書き、OP_CATについて議論の波を引き起こしました。 Andrew PoelstraはBlockstreamのリサーチディレクターであり、業界で強い存在感を示すベテランのBitcoinCryptographyスクリプティング開発者です。

この記事の中で、Andrew Poelstra氏は「OP_CATは、スタック内の2つの要素を結合し、マージされた結果をスタックに戻すのに役立つと説明しています。 この関数を使用して、複数の小さな要素を 1 つの大きな要素に組み立てたり、大きな要素を複数の小さな要素に分解したりできます。 CHECKSIGFROMSTACK (CSFS) は、トランザクションの署名のみを検証する CHECKSIG 操作コードとは異なり、ユーザーが任意のデータに対して署名検証を実行できるようにする、これまでにないビットコインのオペレーションコードです。 」

さらに、OP_CATをCHECKSIGFROMSTACKと組み合わせて使用することで、トランザクションのイントロスペクションに独創的なアプローチを提供できると指摘しています。

注: トランザクションのイントロスペクションとは、スクリプト内のトランザクション自体のさまざまなコンポーネントを調査および分析する機能ビットコインを指します。 簡単に言えば、スクリプトは、トランザクションの出力、金額、または特定の署名のチェックなど、処理しているトランザクションの詳細を「理解」して処理できます。 このようにして、スクリプトはトランザクションの特定のコンテンツに対して、よりインテリジェントで微妙なニュアンスで応答することができます。

これにより、ユーザーはスタック上のトランザクション全体のデータを提供でき、スクリプトは OP_CAT を使用してデータをSINGLE ITEMにパッケージ化し、ハッシュ化してから、データの署名を検証するために CHECKSIGFROMSTACK に渡します。 次に、同じ署名と秘密鍵を CHECKSIG に渡します。 両方の検証に合格すると、ユーザーから提供されたトランザクションデータが実際に実際のトランザクションデータであることを示します。 これにより、スクリプトはこのデータを直接使用して、コントラクトで必要なチェックを実行できます。

Andrew Poelstra氏の影響力と記事のアイデアは、ビットコイン開発者の注目を集め、 その週のカンファレンスでは、 オペレーションコードの組み合わせや、 Taprootのアクティベーション後にスクリプト言語に小さな変更を加えることで、 コントラクトの柔軟性がどのように向上するかについて、 多くの議論が交わされました。

『CAT and Schnorr Tricks I』のリリースから約2週間後、Andrew Poelstra氏は2つ目の記事「CAT and Schnorr Tricks II」を公開し、その中でAndrew Poelstra氏は詳細と彼の考えを語っている。

2019年5月、ビットコイン開発者のJeremy Rubin氏は、以前のスマートコントラクト設計の技術的および社会的リスクを回避する基本的かつ限定的なスマートコントラクトを実装することを目的として、ビットコインのCHECKOUTPUTSHASHVERIFY操作コードを提案しました。 その後、この操作コードは SECURETHEBAG に置き換えられ、その後 CHECKTEMPLATEVERIFY に置き換えられ、2020 年 1 月に正式にビットコイン改善提案 BIP 0119 になりました。

一方、Russell O’Connor氏は、Rubin氏の提案に制約されないスマートコントラクトをサポートするために、CHECKSIGFROMSTACKとOP_CAT操作コードをビットコインに直接追加することを提案しています。 この提案はいくつかの反対に遭い、議論は最終的に減少しましたが、主にCAT+CHECKSIGタイプのスマートコントラクトの非効率性と、完全なユニバーサルスマートコントラクトの保有に対する長期的な否定的な印象が原因でした。

Andrew Poelstra氏も、当初はいわゆるBitcoinSmart Contract機能のサポートに消極的でした。 しかし、2019年秋、イーサン・ハイルマンとのプライベートな交流が彼の考えを変えました。 イーサン・ハイルマン氏は、懸念はあるものの、CHECKMULTISIGを通じて有害と見なされ、認識や可用性の欠如のためにウォレットやユーザーに実際に受け入れられないスマートコントラクトを実装することは実際に可能であると指摘しました。 それを証明するために、イーサン・ハイルマンはソーシャルメディア上で人々に実行可能な「ダーク」スマートコントラクトを考え出すよう呼びかけていますが、これまでのところ誰も成功していません。

そこで、Andrew Poelstra氏は、スマートコントラクトに対するすべての人の恐怖は誇張されているのではないかと考えるようになりました。 また、本稿では、たとえ懸念があったとしても、スマートコントラクトはビットコインの開発において避けられないと主張し、非専用オペレーションコードOP_CATを使用してスマートコントラクトを作成する可能性の継続的な探求を奨励しています。

2021年に

これに続いて、2021 年 7 月 6 日に Jeremy Rubin が、ビットコイン の量子セキュリティの観点から OP_CAT を説明する記事を掲載しました。 ジェレミー・ルービンはビットコイン開発者であるだけでなく、ビットコインスマートコントラクトプログラミング言語であるSapioの開発に焦点を当てたビットコイン研究開発組織であるJudicaの創設者でもあります。

Jeremy Rubin は、電子メールとブログ投稿で、OP_CAT 操作コードと Lamport 署名を使用してビットコインを量子検証する方法について説明しています。 著者はまず、スクリプト演算と Lamport 署名を使用して 5 バイト値を登録する方法に関する以前のブログ投稿ビットコインレビューします。 この方法はすっきりしていますが、制限があります。 Jeremy Rubin は、より長いメッセージに署名できるとしたら、特に 20 バイトまで署名できるとしたら、量子セーフな HASH 160 ダイジェストに署名できるのではないかというアイデアを思いつきました。

Jeremy Rubinは、この記事でHASH 160ダイジェストに署名することの意味をさらに探求し、量子コンピューターがECDSAをクラックした場合でも、実際の署名されたコンテンツを変更せずに秘密鍵のみを明らかにする機能について説明しています。 そのために、著者らは暗号学者のMadars Virza氏に相談し、肯定的な回答を得ました。

Jeremy Rubinは、ECDSA署名を量子証明署名アルゴリズムを使用して署名する必要がある場合、量子証明ビットコインを持つことができると指摘しています。 前述した 5 バイトの署名スキームは、実際には耐量子 Lamport 署名です。 残念ながら、この方法では少なくとも 20 バイトの連続が必要です。

したがって、Jeremy Rubin は、ある種の OP_CAT のような操作が必要であることを提案しました。 この記事では、OP_CAT はスタックを変更するため、Segwit v 0 に直接ソフトフォークすることはできないと説明しています。 そこで、簡単にするために、著者は、セマンティクスを検証することによって、文字列の一部が等しいかどうかを操作コードがチェックする新しい操作コードOP_SUBSTRINGEQUALVERIFYの使用方法を示します。

2021年11月5日、アトランタビットコイン会議で、Jeremy Rubin氏とAndrew Poelstra氏は、Operation Code OP_CATを再び有効にする提案について議論し、OP_CATがビットコインの文脈で重要であると主張し、特に量子安全と複雑なスマートコントラクトの作成の観点から、その可能性を強調しました。 例えば、CATやシュノアの署名検証操作コードと組み合わせることで、非再帰的なスマートコントラクトを理論的に実装することができます。 このスマートコントラクトは、トランザクションデータのSHA 2ハッシュを直接スタックに入れることができます。 そうすることで、取引のさまざまな部分にある程度の制限を課すことができます。

議論では、CATが再導入された場合、新しい機能や可能性が導入される一方で、ビットコインいくつかの点で複雑になる可能性があることも言及されました。 OP_CAT を再起動するには、メモリの爆発など、過去に発生した問題を回避するために慎重に検討する必要があります。

2022

2022 年 5 月 18 日の ビットコイン 開発者メーリングリストで、2010 年にビットコインから削除された OP_CAT 操作コードの再導入に関する議論で、開発者の ZmnSCPxj は、避けられない再帰的スマート コントラクトを実現するには、OP_CAT を OP_TX、OP_CHECKSIGFROMSTACK (CSFS) などの提案された操作コードと組み合わせる必要があることを提案しました。 再帰的スマートコントラクトは、BitcoinConsensusルールを利用して、コントラクトから受け取ったすべてのビットコインが同じコントラクトでのみ使用できるようにします。

再帰的スマートコントラクトは、トランザクションのイントロスペクション技術に依存しており、オペレーションコードは、オペレーションコードが実行されるトランザクションの一部を解析することができます。 既存の操作コードでは、限定的なイントロスペクションが提供されます。 再帰的なスマートコントラクトを作成するには、前の出力と次の出力が同じであることを確認する必要があります。 したがって、前のアウトプット、次のアウトプット、またはその両方を構成要素から動的に構築する必要があるため、再帰的なスマートコントラクトを実装するには、CATまたは同様の構造が必要です。

Nadav Ivgi氏は、再帰的なスマートコントラクトを作成する際にハッシュの問題を解決するにはCATが必要であると指摘していますが、これは、アウトプットのイントロスペクションに焦点を当てたCTVやAPOなどの機能をCATと組み合わせて、再帰的なスマートコントラクトを作成できることを意味します。 Ivgiは、 Taprootの機能と組み合わせて使用すると、 前のアウトプットを次のアウトプットで検証することで、 スマートコントラクトのスクリプティングが書きやすくなると主張し、 2つの再帰的なスマートコントラクトの例へのリンクを提供しています。

ZmnSCPxj氏はIvgi氏の分析に同意し、ビットコイン上で再帰的スマートコントラクトを有効にすることのリスクについて繰り返し懸念を表明しましたが、フォローアップの投稿では、再帰的スマートコントラクトは実際にはチューリング完全ではないため安全である可能性があるとも述べています。 Russell O’Connor氏は、Andrew Poelstra氏の記事を引用し、CAT自体を既存のビットコイン機能と組み合わせて、非再帰的なスマートコントラクトを作成できると説明しており、理論的には、ビットコインに再度追加すれば、再帰的なスマートコントラクトを独自に作成できる可能性があると述べています。

2023年の

1月、Anthony Townsは、提案されたソフトフォークやその他の主要なプロトコルの変更をテストするために、デフォルトのシグネットで動作するように設計されたビットコイン Coreのレプリカであるビットコイン Inquisitionを立ち上げました。 2023年末現在、ビットコイン Inquisitionは多くの提案をサポートしており、さらに、OP_CAT、OP_VAULT、および64バイトのトランザクションを制限するように設計されたPR(プルリクエスト)がコードベースに提出されており、このテストベッドの機能がさらに拡張されることが期待されています。

2023 年 8 月 23 日、Thomas Voegtlin は Lightning-Dev メーリングリストで、期限切れのバックアップのステータスに関する不正防止のアイデアを思いつきました。 Voegtlin氏は、OP_CHECKSIGFROMSTACK(CSFS)とOP_ CAT操作コードがソフトフォーク方式でビットコインに追加されれば、この不正防止をオンチェーンで使用できると指摘しています。 この提案は多くの議論を巻き起こし、Peter Todd氏は、基本的なメカニズムは汎用的であり、LNに限定されず、さまざまなプロトコルで役立つ可能性があると指摘しましたが、ここでは説明しないより単純なメカニズムも提案しました。

10月までに、Rusty Russellは、最小限の変更でビットコインスクリプト言語用の汎用スマートコントラクトに取り組んでいました。 同時に、非常に重要なことに、Ethan Heilman と Armin Sabouri は共同で、スタック上の 2 つの要素を接続するための操作コードである OP_CAT 操作コードの追加を提案する BIP の草案を公開しました。 この2つのテーマに関する議論は11月まで続いた。

2024年に

2024 年 1 月になり、Quantum Cats は BIP と OP_CAT のビットコインプロセスに関する議論を次のレベルに引き上げることに成功しました。

ビットコイン Coreの開発者であるAva Chow氏は、コミュニティとの対話の中で、「CTVは大まかなコンセンサスではないと思います。 他のより一般的なスマートコントラクトの提案は、txhashやCATなど、実際にはより近いと思います。 しかし、私はその議論を詳しく追っていませんでした。 」

コミット数でランク付けすると、Ava Chow(@achow 101)は現在、1,292のコードコミットでビットコインコアコードコントリビューターランキングで5位にランクされており、ビットコインコードをマージする権利を持つ数少ない人の1人です。 その結果、彼女は開発コミュニティでも大きな影響力を持っています。

「OP_CATを発動しろと言っているのではない。 私がOP_CATを支持するのは、コンセンサスに達する可能性が最も高いのは操作コードだからです。 OP_CATについてご存じない方のために、この画像で状況をまとめます。 そう話すのは、 Taproot Wizardの共同開発者であるEric Wall氏(@ercwl)です。

しかし、Ava Chow氏は、OP_CATの実装に絶対的に賛成しているわけではないようです:「すでに述べたように、スマートコントラクトの提案は、大まかなコンセンサスに近づいたり、大まかなコンセンサスを得たりしているとは思いません。 それらのどれもアクティブにしようとするべきではないと思います。 」

スマートコントラクトを実装するための10行ビットコインコード

Taproot Wizardの共同開発者であるEric Wall氏(@ercwl)は、「人々は気づいていませんが、 OP_CATは実際にはビットコイン上のzkrollupの構成要素の1つです。 」

OP_CATの再導入により、OP_CATのおかげでより簡単かつ効率的になる、ビットコイン上で任意の計算を検証するという最近導入された概念であるBitVMのようなプロジェクトをサポートする強力なツールがビットコイン提供されます。 ビットコインエコシステムは、より汎用性が高く表現力豊かなスマートコントラクトの作成を可能にします。

関連レディング: ベテラン開発者は、ビットコインで何かを計算するためのBitVMについてどう考えていますか?

OP_CATでは、いわゆるスマートコントラクト、つまり特定のビットコイン出力に対して事前に指定された条件を設定することができます。 これにより、BlockstreamのArkのような新しいスケーリング方法への扉が開かれるだけでなく、スマートコントラクトに依存する他の多くの革新的なアプローチもサポートされます。 さらに、ビットコインが単なる決済ネットワークではなく、多用途でスケーラブルなコンピューティングプラットフォームであることを意味します。

Taproot Wizardの共同開発者であるEric Wall氏は、BitVMの背後にあるコンセプトに興奮していますが、その巨大なオーバーヘッドと長い実装サイクルのために、この提案はビットコインにとって「技術的な行き詰まり」になる可能性があると考えています。 彼は、BitVMがコミュニティの注意をそらし、真の開発を妨げるのではないかと心配しています。 それにもかかわらず、BitVMの提案は、ブロックチェーン技術とスマートコントラクトの分野における積極的な探求と革新の精神を示しています。

実際、Taproot Wizardのプロジェクトチーム自体も、ビットコイン上でレイヤー2ソリューションの実装に取り組んでおり、以前のスペースでは、完了した750万ドルの資金調達ラウンドは、ビットコインスケーリングオプションの研究に使用されるとも述べています。

したがって、OP_CATのソフトフォークも彼らにとって重要なステップになります。 StarkNet Foundationの理事を務めていたEric Wall氏は、パーミッションレスな決済レイヤーの構築に加えてDeFiを構築することに大きな関心を持っているため、2019年にイーサリアムが登場し始めたとき、彼は自然とイーサリアム上の分散型金融空間に惹かれました。

ビットコインの分散型金融の探求は、2019年にイーサリアムやその他のブロックチェーンがzkロールアップや楽観的な不正防止を使用することで拡張できることが明らかになったとき、ほぼ完全に放棄されました。 ビットコインに適用されるzk-rollupスケーリングの実現可能性に関する研究により、Wallはイーサリアム上の分散型金融をサポートするようになりました。 しかし、最終的には、このシステムとこれらの技術的利点をビットコインに持ち込もうとしています。

さらに、bitcointalkフォーラムのOP_CATに関するディスカッションスレッドで、QEDプロジェクトの創設者であるカーター・フェルドマン(@cmpeq)は、この操作コードをビットコインスクリプトでどのように活用するつもりなのか、また、証人スタックの平均バイト数と発生する可能性のある手数料を計算するのかを尋ねられました。

Carter Feldman氏は、これは少し高価であることは認識しているが、Merkel proofは主に、ビットコイン上のzkレイヤー2の一部としてトラストレスなロックスクリプトまたはペグシステムを構築するプロジェクトで使用されていると説明しています。 このシステムは、引き出しツリーのルートが与えられた場合、特定のアドレスに一定量のビットコインを引き出すことができることを証明することを目的としています(ゼロ知識証明への公開入力として)。

コストに対処するために、彼はこれが最後の手段になると述べました。 彼は、通常のユーザーが、ラップされたBTCの売り手に一定期間L2にトークンをロックさせ、その間、買い手はL1で売り手に支払ったことを証明しなければならないことで、第2層でラップされたBTCビットコイン購入できると想定しています。 彼らは、その気になればいつでもトラストレスでビットコイン交換できることを知っています。 同時に、いくつかの大規模な流動性プロバイダーは、wBTCとBTCの間で実際にスワップするエンティティになり、wBTCを購入したり、ビットコインにブリッジバックしたりしたい小規模なユーザーに少額の手数料を請求する可能性があります。

したがって、一般的に、OP_CATのBIP提案は、わずか13行のコードでビットコイン上でスマートコントラクトを構築するのに役立ちますが、各プロジェクトの具体的な詳細についてはまだ多くの議論と試行ソリューションがあります。

ミーム文化は勢いを増し、テクノロジーを進歩させる

TaprootWizardsのチームメンバーであるRijndael(@rot 13 maxi)は、アートワークの作成に使用しているさまざまな複雑なメカニズムをソーシャルメディアで共有しました。 これを実現するために、序数再帰、署名済みトランザクション、対称暗号化、クライアント側の負荷管理など、さまざまな手法に依存しています。 アートを作成する過程で、彼らは特に事前署名されたトランザクションを使用して操作を実行することを選択し、OP_CATやCTVなどのスマートコントラクトを使用してトランザクションのハッシュを事前送信する方法を示しました。

しかし、Armin Sabouri氏は皮肉を込めて、「進化する非代替性トークンのコレクションを作成するために必要なコードと技術的労力は、オペレーションコードを再度有効にするために必要な作業量の100倍になる可能性があります。 」

OP_CATはシンプルでわかりやすい操作コードとされており、ECDSA署名に署名することでビットコインを「量子セキュア」にできると主張されています。 このアイデアは一部の人に支持され、Taproot WizardがOP_CATの認知度を高めるためにQuantum Cats Non-fungible Tokenキャンペーンを開始するきっかけとなりました。

しかし、ミーム文化を利用して技術進歩の勢いをつけているのは、OP_CATだけではありません。

Quantum Catsとその0.1 BTCの販売価格に触発され、おそらくその高い販売価格に不満を抱いていたOP_CTVコミュニティは、OP_CTVの技術を促進するために #rubinsreubens と呼ばれるサンドイッチミームを立ち上げました。

このサンドイッチミームはもともと、量子猫とそのミームに対するユーモラスな反応として意図されていました。 しかし、CTVのように階層が追加され、「sammich」に好きなだけレイヤーを作ることができるので、実際には非常に効果的です。

このサンドイッチミームは、多くの人々の注目を集めています。 ミームは面白く、何かへの支持を示すために使用できますが、その背後にある意味を理解することも重要です。 #rubinsreubens の目的は、新しいBTCオペレーションコードとスマートコントラクトの有効化に関するOP_ctv、LNHANCE、およびソフトフォークの提案の理解を深めることです。

OP_CAT 失敗の考えられる原因

OP_CAT に話を戻すと、OP_CAT のような機能の導入に反対する人は、さまざまな理由から反対するかもしれません。 第 1 に、新しいオペレーション コードや OP_CAT などの機能を追加すると、ビットコインの複雑さが増し、理解と使用のセキュリティがより困難になり、リスクが高まる可能性があります。 第 2 に、新機能を導入する際のセキュリティの問題は見落とされるべきではなく、完全にテストされていない機能には、ビットコイン の全体的なセキュリティを損なう脆弱性が潜んでいる可能性があります。 さらに、ソフトフォークのアップグレードがすべてのノードで採用されていない場合、ネットワークが分割され、異なるバージョンのビットコインネットワークが共存し、コンセンサスに達することがより複雑になる可能性があります。

新機能は、特に古いノードをサポートしていない場合、互換性の問題を引き起こす可能性があり、ネットワークから一部のノードが除外され、ビットコインエコシステムに悪影響を与える可能性があります。 特に、アップグレードしていないユーザーは、ネットワークへの参加を継続できなくなる可能性があります。 さらに、新機能の導入は、ビットコインのコアプロトコルの差し迫った問題への対処を優先せずに、性急な決定と見なす人もいるかもしれません。 性急な変更は、不必要なリスクと不安定さをもたらす可能性があります。

セキュリティとリスクの考慮事項に加えて、OP_CATが失敗する2つの最大の理由は、ビットコインコミュニティにおけるスマートコントラクトへの恐れと、ビットコインスマートコントラクトの「正当性」の欠如です。

スマートコントラクトへの恐怖

ビットコインスマートコントラクトへの恐怖は、OP_CATを達成するためのもう一つの大きな障害になる可能性があります。 ブロックチェーン技術のコアコンポーネントとして、スマートコントラクトは多くのブロックチェーンプロジェクト、特にイーサリアムなどのプラットフォームで重要な役割を果たしています。

しかし、ビットコインコミュニティでは、スマートコントラクトがもたらすリスクや課題への懸念もあり、スマートコントラクトの受け入れ率は比較的低いです。 スマートコントラクトは、ピアツーピア、分散化、セキュリティなど、ビットコインのコアバリューに影響を与える可能性があります。 ビットコインコミュニティは、これらのコアバリューを維持することを非常に真剣に受け止めており、これらのバリューを脅かすと見なされる変更は反対される可能性があります。

スマートコントラクトの主な懸念は、ネットワーク全体の複雑さとセキュリティリスクを増大させる可能性があることです。 スマートコントラクトには複雑なロジックやコードが含まれることが多く、小さなバグや脆弱性は深刻なセキュリティ問題や、過去に一部のブロックチェーンプロジェクトで起こったように、巨額の資金損失につながる可能性があります。 さらに、スマートコントラクトの導入により、システム全体の理解と監査が困難になり、エラーの可能性が高まる可能性があります。

さらに、ビットコインコミュニティは、ネットワークの安定性とセキュリティを維持することに常に大きな重点を置いてきました。 ビットコインの設計哲学は、シンプルさと保守主義に傾き、ネットワークのセキュリティと分散化を優先しています。 その結果、サイバーの安定性に脅威をもたらす可能性のある重要な変更は、厳しい精査と広範な議論の対象となります。 OP_CATとスマートコントラクトの導入は、ビットコインに新しい機能と可能性をもたらす可能性がありますが、ビットコイン当初のビジョンと設計哲学に反すると見なされる可能性もあります。

サトシ・ナカモトは「間違っていた」のか?

OP_CAT操作コードの復元は、サトシ・ナカモトが間違っていることを意味するというデリケートなトピックに触れていることもあり、コミュニティで深い議論を巻き起こしました。

ビットコインの創始者として、サトシ・ナカモトの決断と独創的なデザインは多くの人にバイブルとして支持されており、彼の独創的なビジョンはビットコインの発展の中心的な指針と見なされています。 したがって、サトシ・ナカモトの決定に対するいかなる種類の異議申し立てや修正も、彼の遺産に対する無礼、またはビットコインの基本原則からの逸脱と見なされる可能性があります。 結局のところ、ブロックチェーン業界では、正当性は常に避けられないトピックでした。

したがって、OP_CATを復活させるという提案は、ビットコイン静的な存在であるべきか、それとも変化する技術環境とユーザーのニーズに適応すべきかという、より広範な問題にも触れています。

しかし、技術分野は常に進歩し変化しており、ビットコインは技術革新としてこの法則を完全に取り除くことはできず、OP_CATの復元をサポートするTaproot Wizardチームはそう考えているようです。 結局のところ、彼らは意図的に、ビットコイン4MBの制限をわずかに下回る史上最大のBitcoinBlockを設計し、Non-fungible Token Taproot Wizardsをリリースしました。

Taproot Wizardの創設者であるUdi Wertheimer氏は、多くの人がビットコインは変わるべきではないと考えていることを理解していると述べています。 彼は、ビットコインの変化はゆっくりと、慎重で、慎重に行うべきだと考えています。 彼は、ビットコイン完全に固まるには若すぎると主張し、ガバナンスプロセスが何らかの形で壊れていると指摘しています。 技術コミュニティは、ビットコインにさらに多くのアップグレードがあることに同意していますが、どのアップグレードになるかを正確に決定することは非常に困難です。 それでも、ヴェルトハイマー氏は、現在のビットコインはまだ何十億人もの人々にサービスを提供できていないため、変化が必要であると強調しました。

もちろん、このような変更には、セキュリティの問題、ネットワークの断片化のリスク、互換性の問題などのリスクと課題も伴い、慎重に検討して対処する必要があります。

予想通り、今後、提案された改善が安全で効果的であることを保証するために、テストネット環境にOP_CATを展開することは、開発者がメインネットに影響を与えることなく問題を特定して解決できるようにする重要なステップです。

同時に、OP_CATの「再開」を真に実現するためには、技術的な詳細、コミュニティのコンセンサス、ネットワークのセキュリティと安定性への配慮、そして最も重要なこととして、幅広いコミュニティの支持と認識など、多くの考慮事項とバランスビットコイン伴うため、プロセス全体が長期間、さらには数年にわたって続くことになります。