原作者：Jaleel，BlockBeats

ビットコインのコードベースにおいて、かつてサトシ・ナカモトによって削除され、歴史に塵を積んでいたオペコード「OP_CAT」が「復活」する可能性がある。

OP_CAT オペレーション コードを中心に、ビットコイン NFT プロジェクト Taproot Wizards が NFT Quantum Cats の新シリーズを立ち上げ、コミュニティでの激しい議論を巻き起こしました。 OP_CATという名前は私たちがよく知っている「猫」を指しませんが、Taproot Wizardは猫の画像を使用してQuantum Catsと呼ばれる新しいNFTを販売し、OP_CATの勢いを高めるためにミーム文化を使用しました。関連書籍:ビットコイン「Quantum Cat」: スマート コントラクトがなければ、碑文はどのようにして動的に変化するのでしょうか?》

OP_CATは、かつてサトシ・ナカモトによってビットコインスクリプト言語から削除されたオペコードですが、現在再び議論のテーブルに戻されています。一部のビットコイン開発者は、このオペコードを「復活」させ、13行のコードソフトウェアを使用したいと考えています。ビットコインがスマートコントラクトを実装する方法。ビットコイン開発者と猫のミーム画像によって、OP_CAT に関する人気と議論は新たな高みに達しました。

「復活」オペコードはサトシ・ナカモトによって削除されました

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

OP_CAT はもともと公式の Bitcoin コマンド セットの一部であり、2 つの要素を 1 つに結合する文字列連結操作を許可していました。しかし、OP_LSHIFT などのオペコードで見つかった深刻な脆弱性により、ビットコイン ノードがクラッシュする可能性があり、OP_CAT オペコードによりスタック要素が指数関数的に増加する可能性があるという懸念があるため、スクリプト サイズに応じてメモリ使用量が指数関数的に増加する可能性があります。

したがって、サトシ・ナカモトは警戒して、2010 年 8 月 15 日に OP_CAT を削除しました。これらの削除されたオペコードはよく「禁止された」と呼ばれますが、プロトコルから完全に削除され、ビットコインを使用している人は誰でも使用できなくなるため、これは不正確です。

2023年10月、ビットコインコア開発者のイーサン・ヘイルマン氏とボタニックス研究所のチーフソフトウェアエンジニアであるアルミン・サブウリ氏が共同で「OP_CAT」と呼ばれるビットコイン改善提案書（BIP）の草案を発表し、この議論を新たなレベルに引き上げた。

このドラフトには 13 行の簡潔なコードしか含まれていませんが、明確で直観的な機能特性が含まれており、スタック上の 2 つの値の連結を可能にする新しいタップスクリプト オペコードが定義されています。このコード実装は明らかに、元の削除された OP_CAT からインスピレーションを得ています。

「復活」の条件を満たした

サトシ・ナカモトによって削除されたオペコードが現在開発者によって復元されることが期待されている理由については、この BIP ドラフトの動機のセクションでいくつかの詳細な説明が提供されています: これは主にメモリ使用量の考慮に基づいています OP_CAT によりスクリプトの構築が可能になります メモリ使用量は指数関数的に増加する可能性がありますスクリプト自体のサイズによって異なります。具体的には、1 バイトの値をスタックにプッシュし、OP_DUP オペコードでコピーし、OP_CAT オペコードと 40 回連結するだけの単純なスクリプトによって、スタック値が 1 TB を超える巨大な規模に膨れ上がる可能性があります。

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

OP_CAT は、より複雑で強力なスクリプトを構築する際の潜在的な価値を主な理由として、再び議論され、再開が検討されていることがわかります。さらに、次のようないくつかの原因と変化が「復活」の条件を満たしました。

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

2. 他のチェーンでの成功例: Bitcoin Cash やサイドチェーン Liquid などの一部の Bitcoin フォークは、OP_CAT を再度有効にし、それを使用してトークンの作成と管理、支払いチャネル、およびゾーン内にデータを埋め込んで取得する方法を実装しました。ブロックチェーン。これは、OP_CAT が適切な状況と制約の下で安全かつ効果的に使用できることを示しています。

3. 量子セキュリティの探求: 一部の研究では、OP_CAT などの操作をランポート署名などの技術と組み合わせて使用​​できれば、量子安全なビットコイン トランザクションとプロトコルを構築できることが提案されています。この探査には、ビットコイン システムの将来のセキュリティを向上させる潜在的な価値があります。

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

ソフトフォーク、言うは易く行うは難し

技術レベルでは、OP_CAT ほど解読および理解が容易なビットコイン提案はほとんどありません。ただし、OP_CAT オペコードは、オペコード OP_SUCCESS 126 を再定義するソフト フォークを通じてアクティブ化されますが、これは明らかに簡単な作業ではありません。

3 年前に発生したビットコインの最新のソフトフォークを振り返ると、Taproot の活性化により Ordinals の誕生への道が開かれました。

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

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

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

3. 変更と改善: コミュニティからのフィードバックに基づいて、コードの作成者は提案を変更および改善する必要がある場合があります。

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

5. コードの実装: 合意に達すると、コードは Bitcoin Core 開発者チームによってレビューされます。このステップは、コードの品質とセキュリティを確保するために必要です。

6. コードベースにマージ: レビューに合格した後、コードはビットコインの公式コードベースにマージされます。

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

明らかに、OP_CAT ソフトフォークの実装はまだ非常に初期段階にあります。BIP 草案が作成されてから 4 か月も経っていません。BIP 番号はまだ決定されていません。まだ提案書を作成する最初の段階にあり、第 2 段階には、開発者とユーザーが参加するコミュニティ ディスカッション セッションが含まれます。

ビットコイン開発者の発言

まず、近年のビットコイン開発者による OP_CAT の議論に特別な注意を払ってみましょう。

OP_CAT オペコードは削除されましたが、高度なコントラクトを容易にし、ビットコイン スクリプト言語を強化する上での OP_CAT の潜在的な有用性については、開発者の間で繰り返し議論されてきました。たとえば、スタック値を連結する機能は、OP_CAT がサポートされていればトランザクション サイズが大幅に削減される可能性がある TumbleBit など、一部のビットコイン プロトコルの開発の妨げになると考えられています。

Optech ニュースレターとさまざまな関連コンテンツを収集した後、以下は一部のビットコイン開発者による OP_CAT オペコードに関する議論を時系列にまとめたものです。

2019年

この「OP_CAT」ビットコイン改善提案（BIP）草案の発起人の一人であるイーサン・ヘイルマン氏（2019年10月）ちょうどメールで同氏は、削除された理由は理解していると述べたが、当時スクリプトが直面していた状況が極めて厳しいものだったためだが、OP_CATはオペコードであり、その値は無視できないと強調した。「現在ビットコイン上に構築しようとしているほとんどのプロトコルは、 1 つの制限: スタック値を連結することはできません。研究者として、この制限に遭遇した場合、他の研究者の進歩を妨げる可能性があります。杖を振って、無効になったオペコードの 1 つを再度有効にすることができれば、OP_CAT はもちろん、これには条件があります。連結された各値のサイズは 64 バイト以下に制限される必要があります。」

OP_CAT の議論に関して言えば、Andrew Poelstra は決して無視できない人物です。彼は2021年1月30日に「」というタイトルの記事を書いた。CAT and Schnorr Tricks I「この記事は OP_CAT に関する議論を引き起こしました。 Andrew Poelstra は、Blockstream のリサーチ ディレクターであり、ビットコイン暗号化スクリプト作成の上級開発者であり、業界における彼の影響力は自明です。

この記事の中で、Andrew Poelstra 氏は次のように紹介しています。「OP_CAT は、スタック内の 2 つの要素を結合し、結合した結果をスタックに戻すのに役立ちます。この関数は、複数の小さな要素を 1 つの大きな要素に組み立てたり、大きな要素を組み立てたりするために使用できます。 」

さらに重要なのは、OP_CAT を CHECKSIGFROMSTACK と組み合わせて使用​​すると、トランザクション イントロスペクションの賢い方法が提供されると彼は指摘しています。

注: トランザクションのイントロスペクションとは、ビットコイン スクリプト内のトランザクション自体のさまざまなコンポーネントを検査および分析する機能を指します。簡単に言うと、スクリプトは出力内容、金額、トランザクションの特定の署名の確認など、処理中のトランザクションの詳細を「理解」して処理できるようになります。こうすることで、スクリプトはトランザクションの詳細に基づいて、よりインテリジェントかつ詳細に応答できます。

この方法で、ユーザーはスタック上のトランザクション全体のデータを提供し、スクリプトは OP_CAT を使用してこのデータを 1 つの項目にパッケージ化し、ハッシュし、CHECKSIGFROMSTACK に渡してデータの署名を検証します。次に、同じ署名とキーを CHECKSIG に渡します。両方の検証に合格した場合、ユーザーが提供したトランザクション データが実際のトランザクション データであることを意味します。このようにして、スクリプトはこのデータを直接利用して、コントラクトで必要なチェックを実行できます。

Andrew Poelstra の影響とこの記事の着想は、ビットコイン開発者の注目を集め、その週の会議では、このオペコードの組み合わせとスクリプト言語への小さな変更がタップルートのアクティブ化にどのように改善されるかについての議論が行われました。契約の柔軟性について。

距離CAT and Schnorr Tricks I』の発売から約2週間。CAT and Schnorr Tricks II」の中で、アンドリュー・ポールストラは詳細と自身の考えを次のように語っています。

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

一方、Russell OConnor氏は、Rubin提案の対象ではないスマートコントラクトをサポートするために、CHECKSIGFROMSTACKおよびOP_CATオペコードをビットコインに直接追加することを提案しました。この提案には一部の反対があり、主に CAT+CHECKSIG タイプのスマート コントラクトの非効率性と、包括的なユニバーサル スマート コントラクトに対する長年の否定的な認識により、議論は最終的には沈静化しました。

アンドリュー・ポールストラ氏も当初はビットコインのいわゆるスマートコントラクト機能のサポートに消極的でした。しかし、2019 年の秋、イーサン・ヘイルマンとの個人的な会話が彼の考えを変えました。イーサン・ヘイルマン氏は、懸念にもかかわらず、有害と考えられるスマートコントラクトはCHECKMULTISIGを通じて実際に実装可能であり、そのようなコントラクトは認識や使いやすさの欠如により実際にはウォレットやユーザーに受け入れられていないと指摘しました。これを証明するために、イーサン・ヘイルマン氏はソーシャルメディア上で実行可能な「ダーク」スマートコントラクトを考案するよう人々に奨励するチャレンジを開始したが、これまでのところ誰も成功していない。

そこで、アンドリュー・ポールストラ氏は、スマートコントラクトに対する誰もが抱く恐怖は誇張されているのではないかと考えるようになった。この記事はまた、たとえ懸念があるとしても、ビットコインの開発においてスマートコントラクトは避けられないと提案し、非特定のオペコード OP_CAT を使用してスマートコントラクトを作成する可能性の継続的な探求を奨励しています。

2021年

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

存在する郵便そしてブログ投稿, Jeremy Rubin が、ビットコインの量子検証に OP_CAT オペコードと Lamport 署名を活用する方法について説明します。著者はまず、ビットコイン スクリプト演算と Lamport 署名を使用して 5 バイト値を登録する方法を説明した以前のブログ投稿を確認しました。この方法は優れていますが、制限もあります。 Jeremy Rubin は、より長いメッセージに署名できたらどうなるだろうかというアイデアを思いつきました。特に、最大 20 バイトまで署名できれば、量子的に安全である可能性のある HASH 160 ダイジェストに署名できます。

Jeremy Rubin の記事では、HASH 160 ダイジェスト署名の意味をさらに調査し、実際の署名の内容を変更せずに秘密キーのみを明らかにするために ECDSA を破る量子コンピューターの能力について説明しています。この目的のために、著者は暗号学者のマダース・ヴィルザに相談し、肯定的な答えを得ました。

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

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

2021 年 11 月 5 日アトランタビットコインカンファレンス講演者のジェレミー・ルービン氏とアンドリュー・ポールストラ氏は、オペコードOP_CATを再度有効にする提案について議論し、ビットコインの文脈においてOP_CATが重要であると主張し、特に量子セキュリティと生産におけるその可能性を強調した。たとえば、CAT と Schnorr 署名検証オペコードを組み合わせると、理論的には非再帰的スマート コントラクトを実装できます。このスマート コントラクトは、トランザクション データの SHA 2 ハッシュをスタックに直接置くことができます。そうすることで、トランザクションのさまざまな部分にある程度の制限を課すことができます。

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

2022年

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

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

Nadav Ivgi 氏は、再帰的スマート コントラクトを作成するときにハッシュ問題を解決するには CAT が依然として必要であると指摘しましたが、これは、出力イントロスペクションに焦点を当てた CTV や APO などの機能も CAT と組み合わせて再帰的スマート コントラクトを作成できることを意味します。 Ivgi は、taproot の機能と組み合わせると、前の出力を次の出力で検証することでスマート コントラクト スクリプトの記述が容易になると考えており、2 つの再帰的スマート コントラクトの例へのリンクを提供しています。

ZmnSCPxj は Ivgi の分析に同意し、ビットコインで再帰的スマート コントラクトを有効にするリスクについての懸念を繰り返しましたが、フォローアップの投稿では、再帰的スマート コントラクトは実際にはチューリングが完了していないため安全である可能性があるとも指摘しました。ラッセル・オコナー氏はアンドリュー・ポールストラ氏の記事を引用し、CAT自体を既存のビットコイン機能と組み合わせることで、非再帰的なスマートコントラクトを作成するには十分であり、理論的には、ビットコインに追加し直せば、その上で再帰を作成できる可能性があることを説明した。独自のスマートコントラクト。

2023年

1 月、Anthony Towns は、デフォルトのシグネット上で実行するように設計された Bitcoin Core のソフトウェア フォークである Bitcoin Inquisition を立ち上げ、提案されたソフト フォークやその他の主要なプロトコル変更をテストするために使用されました。 2023 年後半の時点で、Bitcoin Inquisition は複数の提案をサポートしており、さらに、OP_CAT、OP_VAULT、および 64 バイトのトランザクション制限を対象とした PR (プル リクエスト) がコード ベースに送信されており、このテスト プラットフォームがさらに拡張されることが期待されています。関数。

2023 年 8 月 23 日、Lightning-Dev メーリングリストについて, Thomas Voegtlin は、期限切れのバックアップ状態の不正行為を証明するアイデアを提案しました。 Voegtlin 氏は、OP_CHECKSIGFROMSTACK (CSFS) および OP_CAT オペコードがソフト フォークの形でビットコインに追加された場合、チェーン上でこの不正行為の証拠を使用することが可能になると指摘しました。この提案は多くの議論を引き起こし、Peter Todd 氏は、基本的なメカニズムは LN に限定されず普遍的であり、さまざまなプロトコルで役立つ可能性があると指摘しましたが、より単純なメカニズムも提案しましたが、ここでは説明しません。

10 月までに、Rusty Russell はビットコイン スクリプト言語への変更を最小限に抑えた汎用スマート コントラクトの開発に取り組んでいました。同時に非常に重要なことですが、イーサン・ヘイルマンとアーミン・サブリは共同でドラフトBIPは、スタック上の 2 つの要素を連結するために使用される OP_CAT オペコードの追加を提案しました。これら 2 つの問題に関する議論は 11 月まで続きました。

2024年

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

コミュニティとの交流の中で、Bitcoin Core 開発者Ava ChowZeng 氏は、「CTV が大まかなコンセンサスだとは思わない。txhash や CAT など、他のより一般的なスマート コントラクトの提案が実際にはそれに近いと思う。しかし、私はその議論を詳しく見ていない。」と述べた。

現時点での投稿数順に並べると、Ava Chow（@achow 101 ）存在するBitcoin Core コード貢献者ランキング彼は1292のコード提出で5位にランクされており、ビットコインコードをマージする権利を持つ数少ない人物の1人でもある。したがって、開発コミュニティにおける彼女の影響力も非常に大きいです。

「私はOP_CATを有効にすることを提案しているわけではありません。私はOP_CATを支持します。なぜなら、OP_CATはコンセンサスに達する可能性が最も高いオペコードだからです。OP_CATで何が起こっているのかわからない場合は、この図に状況をまとめました。」魔法使いの連荘Eric Wall （@ercwl） そう言いました。

しかし、Ava ChowOP_CAT の実装に絶対的な承認があるわけではないようです。「すでに述べたように、スマート コントラクトの提案は大まかなコンセンサスに近づいていないか、大まかなコンセンサスに達しているとは思えません。そのいずれも有効化しようとすべきではないと思います。」

10 行のコードでビットコインにスマート コントラクトを実装できる

Taproot Wizardの共同制作のようにEric Wall （@ercwl) は次のように述べています。「人々はこれに気づいていませんが、OP_CAT は実際にはビットコインの zkrollup の構成要素の 1 つです。」

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

関連書籍:ビットコインで何かを計算する場合、上級開発者は BitVM についてどう考えていますか?》

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

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

実際、Taproot Wizard プロジェクト チーム自体もビットコインの第 2 層ソリューションの実装に取り​​組んでおり、以前の Space では、完了した 750 万米ドルの資金調達はビットコイン拡張ソリューションの研究に使用されると述べています。

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

2019年にイーサリアムやその他のブロックチェーンがzk-Rollupsや楽観的詐欺証明の使用を通じて拡張できることが明らかになったとき、ビットコインによるDeFiの探求はほぼ完全に放棄されていました。 「ビットコインに適用されるzk-Rollup拡張の実現可能性」などの問題に関する研究により、ウォール氏はイーサリアムでのDeFiのサポートに目を向けました。しかし最終的に、彼はこのシステムと技術的な利点をビットコインに導入しようとしています。

さらに、bitcointalk フォーラムの OP_CAT に関するディスカッション スレッド内, QED プロジェクトの創設者である Carter Feldman (@cmpeq) は、ビットコイン スクリプトでこのオペコードをどのように利用する予定であるか、また監視スタックの平均バイト数とそれによって発生する可能性のある料金を計算したかどうかを尋ねられました。

カーター・フェルドマン氏は、これには少々費用がかかるかもしれないことを認めたが、メルケル首相の証明は主に、ビットコイン上のzkの第2層の一部としてトラストレス・ロッキング・スクリプトまたはペグ・システムを構築するプロジェクトで使用されていると説明した。このシステムは、出金ツリーのルート (ゼロ知識証明としての公開入力) を考慮して、特定のアドレスに一定量のビットコインを出金できることを証明するように設計されています。

コストの問題に対処するには、これは最後の手段であると同氏は述べた。同氏は、ラップBTCの売り手に一定期間トークンをL2にロックさせることで、一般ユーザーが第2層でラップBTCを購入できるようにし、その間、買い手はビットコインL1にコミットしたことを証明する必要があると構想した。 。彼らは、希望すればいつでもビットコインをトラストレスに交換できることを知っています。同時に、いくつかの大手流動性プロバイダーがwBTCとBTCの間で実際に取引を行う主体となり、そこからwBTCを購入したりビットコインに戻したりしたい小規模ユーザーに少額の手数料を請求する可能性がある。

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

ミーム文化の勢い構築テクノロジーの進歩

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

しかし、Armin Sabouriはこれについて皮肉なコメントをしました：「進化するNFTコレクションの作成に投資されたコードと技術的労力は、オペコードを再度有効にするために必要な作業量の100倍になる可能性があります。」

OP_CAT はシンプルで理解しやすいオペコードとみなされており、ECDSA 署名に署名することでビットコインを「量子安全」にできると考える人もいます。この見解は一部の人に支持され、Taproot Wizard がこれらの活動を通じて OP_CAT の認知度を高めるために Quantum Cats NFT プロモーションを開始するきっかけとなりました。

ただし、ミーム文化を利用してテクノロジーの進歩の勢いを高めているのは OP_CAT だけではありません。

Quantum Cats とその販売価格 0.1 BTC に触発され、おそらくその高い販売価格に部分的に不満を抱いていた OP_CTV コミュニティは、OP_CTV のテクノロジーを宣伝するために #rubinsreubens というサンドイッチ ミームも立ち上げました。

このサンドイッチ ミームは、Quantum Cat とそのミームに対するユーモラスな反応として始まりました。ただし、CTV と同様に階層が追加され、「サミッヒ」に必要なだけレイヤーを作成できるため、実際には非常に効果的です。

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

OP_CAT 失敗の考えられる理由

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

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

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

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

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

しかし、ビットコイン コミュニティ内でのスマート コントラクトの受け入れは比較的低く、その理由の 1 つは、スマート コントラクトがもたらす可能性のあるリスクと課題に対する懸念です。スマートコントラクトは、ピアツーピア、分散化、セキュリティなどのビットコインの中核的価値に影響を与える可能性があります。ビットコインコミュニティはこれらの核となる価値を維持することを非常に真剣に考えており、これらの価値を脅かすとみなされる変更は反対に遭う可能性があります。

スマート コントラクトに関する主な懸念は、ネットワーク全体に複雑さとセキュリティ リスクが追加される可能性があることです。スマート コントラクトには複雑なロジックやコードが含まれることが多く、過去に一部のブロックチェーン プロジェクトで起こったように、小さな間違いや抜け穴が重大なセキュリティ問題や大規模な経済的損失につながる可能性があります。さらに、スマート コントラクトの導入により、システム全体の理解と監査がさらに難しくなり、エラーの可能性が高まる可能性があります。

さらに、ビットコイン コミュニティはネットワークの安定性とセキュリティを維持することに常に重点を置いています。ビットコインの設計哲学はシンプルかつ保守的な傾向があり、ネットワークのセキュリティと分散化を優先しています。したがって、ネットワークの安定性に脅威を与える可能性のある重大な変更は、厳格な精査と広範な議論の対象となります。 OP_CAT とスマート コントラクトの導入は、ビットコインに新しい機能と可能性をもたらす一方で、ビットコインの本来のビジョンと設計哲学に反すると見なされる可能性もあります。

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

OP_CAT オペコードの復元は、コミュニティ内で深い議論を巻き起こしました。これは、デリケートな話題に触れたためでもあります。「これは、サトシ・ナカモトが間違っていたということなのでしょうか?」

ビットコインの創始者であるサトシ・ナカモトの決断とオリジナルのデザインは多くの人からバイブルとみなされており、彼のオリジナルのビジョンはビットコイン開発の中核となるガイドラインとみなされています。したがって、サトシ・ナカモトの意思決定に対するいかなる異議や変更は、彼の遺産を軽視するもの、またはビットコインの中核原則からの逸脱とみなされる可能性があります。結局のところ、ブロックチェーン業界では、正当性は常に避けられないトピックです。

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

しかし、技術分野は常に進歩し変化しており、技術革新であるビットコインもこの法則から完全に逃れることはできないと、OP_CATの復活を支援するTaproot Wizardチームもそう考えているようです。結局のところ、彼らはNFTタップルートウィザードをリリースするために、ビットコインの制限である4 MBをわずかに下回る史上最大のビットコインブロックを意図的に設計していたのです。

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

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

提案された改善が安全かつ効果的であることを確認するには、テスト ネットワーク環境に OP_CAT を展開することが重要なステップとなり、開発者がメイン ネットワークに影響を与えることなく問題を発見して解決できるようになります。

同時に、OP_CAT の「再起動」を真に実現したい場合、技術的な詳細、コミュニティの合意、比較など、多くの考慮事項とバランスが必要となるため、プロセス全体は数年に及ぶ長期間に及ぶことになります。ビットコインネットワークのセキュリティと安定性に関する考慮事項、そして最も重要なのは、広範なコミュニティのサポートと認識です。