13行のコードでビットコインにスマートコントラクトを実現？ OP_CAT ソフトフォークを理解する
TechFlow厳選深潮セレクト
13行のコードでビットコインにスマートコントラクトを実現？ OP_CAT ソフトフォークを理解する
ビットコインは歴史的な岐路に立っている。OP_CATの再有効化を擁護してスマートコントラクトの探求に向かうか、それとも中本聪の原点に立ち返り純粋性を保つか。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Jaleel、BlockBeats
ビットコインのコードベースにおいて、かつて中本聡によって削除され、長きにわたって歴史の塵に覆われていたオペコード「OP_CAT」が、「復活」する可能性が出てきた。
OP_CATオペコードを巡っては、ビットコインNFTプロジェクトTaproot Wizardsが新たなNFTシリーズ「Quantum Cats」を発表し、コミュニティで大きな話題を呼んでいる。OP_CATという名称が私たちがよく知る「猫」とは直接関係ないにもかかわらず、Taproot Wizardsは猫のイメージを使って「Quantum Cats」というNFTを販売し、ミーム文化を活用してOP_CATの注目度向上に成功した。
かつて中本聡によってビットコインスクリプト言語から削除されたOP_CATというオペコードが、今再び議論の俎上に載せられている。一部のビットコイン開発者たちはこのオペコードの「復活」を目指しており、わずか13行のコードによるソフトフォークを通じて、ビットコインでのスマートコントラクト実現への道を開こうとしている。開発者の推進と猫のミームイメージを用いたキャンペーンにより、OP_CATに対する注目と議論は新たな高みに達している。
中本聡が削除したオペコードの「復活」
オペコード（Opcodes）とは命令または関数とも呼ばれ、ビットコインスクリプト言語の基本的な構成要素である。過去、クライアント実装における潜在的な脆弱性への懸念から、初期のビットコインバージョンではいくつかのオペコードが削除されており、OP_CATもその一つだった。
OP_CATは当初、ビットコイン公式コマンドセットの一部であり、文字列連結操作を可能にするものだった。つまり、2つの要素を結合して1つにまとめる機能を持つ。しかし、OP_LSHIFTなどのオペコードで深刻な脆弱性が発見され、任意のビットコインノードをクラッシュさせる可能性があることが判明した。また、OP_CAT自体がスタック要素を指数関数的に増加させ、スクリプトサイズに対してメモリ使用量が指数関数的に膨張するリスクがあると考えられた。
このため、中本聡は慎重を期して2010年8月15日にOP_CATを削除した。これらの削除されたオペコードは一般的に「無効化」と呼ばれるが、正確にはプロトコルから完全に削除されているため、誰もそれらを使用できなくなっている。
2023年10月、Bitcoin Core開発者のEthan HeilmanとBotanix Labsの最高ソフトウェアエンジニアArmin Sabouriが共同で、ビットコイン改善提案（BIP）の草案を公開した。その名も「OP_CAT」であり、これにより議論は新たな段階に入った。
この草案はわずか13行の簡潔なコードからなり、明確で直感的な機能を持つ。新しいtapscriptオペコードを定義し、スタック上の2つの値を連結することを可能にする。このコードの実装は、明らかにかつて削除されたOP_CATに由来している。
「復活」の条件はすでに整っている
なぜ中本聡によって削除されたオペコードが、今になって復活を望まれているのか。このBIP草案の「動機」セクションでは、その理由が詳細に説明されている。主な懸念はメモリ使用に関するもので、OP_CATを使うことでスクリプト生成時のメモリ使用量がスクリプトサイズに対して指数関数的に増大する可能性があった。具体的には、1バイトの値をスタックにプッシュし、OP_DUPで複製し、OP_CATで40回連結するだけでも、スタックの値が1TBを超える規模まで膨張してしまう恐れがある。
しかし、時が経ち技術が進歩したことで、この問題はもはや障壁ではない。tapscriptアーキテクチャのもとでは、スタック要素のサイズが厳密に520バイト以内に制限されるという明確なルールが設けられている。この変更により、OP_CATが引き起こす可能性のあるメモリ使用問題が効果的に解決され、「復活」と統合の道が開かれた。
以上から、OP_CATが再び議論され、使用の再開が検討されているのは、より複雑で強力なスクリプト構築に潜在的な価値があるためだ。さらに、以下の要因が「復活」の条件を満たしている：
1. 高度なスマートコントラクトとプロトコルの需要：ビットコインエコシステムの発展に伴い、より高度で複雑なスマートコントラクトやプロトコルの需要が高まっている。OP_CATはスタック上でオブジェクトを組み合わせることを可能にし、tapscriptの表現力と機能を高める。例えば、Merkleツリーや他のハッシュデータ構造の構築・評価、ツリーシグネチャ、後量子Lamport署名、否認防止契約、ウォレット（保険庫）などへの対応が可能になる。
2. 他チェーンでの成功事例：ビットコインキャッシュ（Bitcoin Cash）やサイドチェーンLiquidといったビットコイン派生チェーンでは、すでにOP_CATが再導入され、トークンの作成・管理、ペイメントチャネル、ブロックチェーン上でのデータ埋め込み・取得方法に利用されている。これは適切な環境と制限のもとで、OP_CATが安全かつ効果的に使用できる証拠である。
3. 量子安全性の探求：OP_CATのようなオペコードとLamport署名などの技術を組み合わせることで、量子耐性を持つビットコインタスクションやプロトコルを構築できるという研究もある。これはビットコインシステムの将来の安全性向上に潜在的な価値を持つ。
4. コミュニティと技術の発展：ビットコインコミュニティと技術の継続的発展により、過去の決定を再考・再評価する動きが生まれている。ビットコインプロトコルへの理解が深まり、新技術が登場する中で、以前は問題があるまたは不適切とされた機能も、新たな文脈で安全かつ有用な応用が可能になっている。
ソフトフォークは決して簡単ではない
技術的には、OP_CATほど解釈・理解が容易なビットコイン提案はほとんどない。だが、OP_CATオペコードはOP_SUCCESS126の意味を再定義することでソフトフォークを介して有効化されるため、決して簡単なことではない。
直近のビットコインのソフトフォークは3年前、Taprootのアクティベーションによって行われた。これにより、Ordinalsの誕生の道が開かれた。
ビットコインコミュニティはコンセンサスと透明性を非常に重視しており、重要なコード変更はすべてコミュニティ内で広く議論・審査される。ソフトフォークも例外ではない。あるコードがビットコインコードベースにマージされるには、厳格かつ詳細なプロセスを経る必要がある。このプロセスは提案の品質とコミュニティの合意を確保するために存在する。主なステップは以下の通り：
1. 提案とコードの作成：まず、開発者は詳細な提案文書を作成する。この文書には、提案の目的、技術的詳細、影響評価、潜在的な問題や課題について明確に記述する必要がある。
2. コミュニティでの議論：コード提案がコミュニティに提出されると、開発者、マイナー、投資家、ユーザーなどのメンバーが議論・審査を行う。この段階は提案の実現可能性を確認し、フィードバックを得る上で極めて重要である。
3. 修正と改善：コミュニティからのフィードバックに基づき、提案者は提案を修正・改善する必要があるかもしれない。
4. 投票と合意形成：特にビットコインプロトコル自体に関わる重要な改善については、一定程度のコミュニティ合意が必要となる。通常、これはマイナーの支持を意味し、彼らが採掘するブロックに特定のシグナルを含めることで提案を支持することを示す。
5. コードの実装：合意が成立すると、コードはBitcoin Core開発者チームによって審査される。このステップではコードの品質とセキュリティが確保される。
6. コードベースへのマージ：審査を通過すれば、コードはビットコイン公式コードベースにマージされる。
7. 展開とアクティベーション：新しいコードはマイナーやノード運営者が自らのシステムに展開する必要がある。プロトコルレベルの変更の場合、通常はアクティベーション閾値が設定され、ネットワーク参加者の十分な割合が新バージョンにアップグレードしない限り、改善は有効にならない。
明らかに、OP_CATのソフトフォーク実現はまだ非常に初期の段階にある。BIP草案の公開からまだ4ヶ月も経っておらず、現在BIP番号さえ割り当てられていない。第1段階（提案とコード作成）から第2段階（開発者やユーザーを含むコミュニティでの議論）に移行したばかりである。
ビットコイン開発者たちの意見は？
ここからは、近年のビットコイン開発者たちによるOP_CATに関する議論に焦点を当てる。
OP_CATオペコードは削除されたものの、高度なコントラクト促進やビットコインスクリプト言語の強化における潜在的な価値については、開発者の間で繰り返し議論されてきた。例えば、スタック値を連結できないことは、TumbleBitなどの特定のビットコインプロトコルの発展を妨げる障壁だと考えられてきた。もしOP_CATがサポートされていれば、それらの取引サイズは大幅に縮小できたはずだ。
Opetechニュースレターおよび関連資料を収集した上で、以下に時間順に、ビットコイン開発者たちがOP_CATオペコードについてどのように議論してきたかを整理する。
2019年
今回の「OP_CAT」BIP草案の共同提唱者の一人であるEthan Heilmanは、2019年10月のメールで、OP_CATが削除された理由を理解しつつも、その価値を強調していた。「当時のスクリプト環境は極めて厳しいものだったが、私はOP_CATというオペコードの価値を軽視できないと考える。現在、ビットコイン上に構築しようとしている多くのプロトコルが直面している制限は、スタック値を連結できないことだ。研究者として、私がこのような制限を感じるのであれば、他の人々の進歩も妨げている可能性が高い。もし魔法の杖で無効化されたオペコードの一つを再有効化できるなら、私はOP_CATを選ぶだろう。もちろん、その際には各連結値のサイズを64バイト以下に制限するという条件を付けるが。」
OP_CATの議論において、Andrew Poelstraは常に避けて通れない人物である。彼は2021年1月30日、「CAT and Schnorr Tricks I」と題する記事を執筆し、OP_CATに関する新たな議論を巻き起こした。Andrew PoelstraはBlockstreamの研究ディレクターであり、業界内でも影響力の大きいビットコイン暗号スクリプトの専門開発者である。
同記事の中でPoelstraは次のように紹介している。「OP_CATはスタック内の2つの要素を結合し、その結果をスタックに戻す機能を持つ。この機能により、複数の小さな要素を1つの大きな要素に組み立てたり、逆に大きな要素を小さな要素に分解したりできる。一方、CHECKSIGFROMSTACK（CSFS）はビットコインにこれまで存在しなかったオペコードで、任意のデータに対する署名検証を可能にするものであり、取引署名のみを検証できるCHECKSIGとは異なる。」
さらに重要なのは、OP_CATとCHECKSIGFROMSTACKを組み合わせることで、巧妙な「取引内省（transaction introspection）」手法を提供できる点だ。
注：取引内省とは、ビットコインスクリプト内で、処理中の取引自体の各構成要素をチェック・分析できる能力を指す。簡単に言えば、スクリプトが「自分自身が処理している取引の詳細情報を理解・処理できる」ようにすること。たとえば、出力内容、金額、特定の署名などをチェックでき、それによりスクリプトは取引の具体的な内容に応じて、より賢く精密な反応ができるようになる。
ユーザーがスタック上に取引全体のデータを提供し、スクリプトがOP_CATを使ってそれらを単一のアイテムにパッケージングし、ハッシュ化してCHECKSIGFROMSTACKに渡して署名検証を行う。その後、同じ署名と鍵をCHECKSIGに渡す。両方の検証が通れば、ユーザーが提供した取引データが実際に正しいものであることが証明される。これにより、スクリプトはそのデータを直接使って、契約に必要なあらゆるチェックを実行できる。
Poelstraの影響力とこのアイデアの独創性は、ビットコイン開発者の注目を集め、翌週の会議では、このようなオペコードの組み合わせや、Taprootアクティベーション後にスクリプト言語に微調整を加えることでコントラクトの柔軟性がどう高まるかについて多くの議論が交わされた。
『CAT and Schnorr Tricks I』の公開から約2週間後、Poelstraは第二弾『CAT and Schnorr Tricks II』を発表。ここではさらに詳しい技術的考察と彼の考えを述べている。
2019年5月、ビットコイン開発者のJeremy Rubinが、基礎的かつ限定的なスマートコントラクトを実施するためのCHECKOUTPUTSHASHVERIFYオペコードを提案した。これは従来のスマートコントラクト設計における技術的・社会的リスクを回避する狙いがあった。このオペコードは後にSECURETHEBAGに置き換えられ、さらにCHECKTEMPLATEVERIFYに更新され、2020年1月に正式にビットコイン改善提案BIP 0119となった。
一方、Russell O'Connorは、Rubinの提案の制限を受けないスマートコントラクトをサポートするため、CHECKSIGFROMSTACKとOP_CATオペコードを直接ビットコインに追加することを提案した。しかし、この提案には反対意見もあり、特にCAT+CHECKSIG型スマートコントラクトの効率の低さや、汎用スマートコントラクトに対する長期的な否定的見解もあり、議論は徐々に下火になった。
当初、Andrew Poelstraもいわゆるビットコインスマートコントラクト機能を支持していなかった。しかし2019年秋、Ethan Heilmanとの非公開のやり取りが彼の考えを変えた。Heilmanは、たとえ懸念があっても、CHECKMULTISIGを使えば「有害」とされるスマートコントラクトを既に実現できると指摘。ただし、それらは認識や使い勝手の面で不足しており、ウォレットやユーザーが受け入れていないと説明した。これを証明するため、HeilmanはSNSで「実現可能な『ダーク』スマートコントラクト」を募集したが、未だに誰も成功していない。
そこでPoelstraは、スマートコントラクトへの恐怖心が誇張されているかもしれないと考えるようになった。彼はその記事で、懸念があるとしても、ビットコインの発展においてスマートコントラクトは避けられないものだとし、専用オペコードを使わないOP_CATによるスマートコントラクトの可能性を探求することを奨励した。
2021年
続いて、2021年7月6日にJeremy Rubinが投稿した記事。彼はビットコイン開発者であるとともに、Judicaの創設者でもあり、これはビットコインスマートコントラクト言語Sapioの開発に特化した研究組織だ。
彼のメールとブログ記事では、OP_CATオペコードとLamport署名を用いたビットコインの量子耐性化について述べている。まず、ビットコインスクリプトの算術演算とLamport署名を用いて5バイト値を登録する方法について前稿を振り返る。この方法は洗練されているが、限界がある。Rubinはこう問いかけた。「もっと長い情報を署名できたらどうか？特に最大20バイト署名できれば、量子耐性を持つ可能性のあるHASH160ダイジェストを署名できる。」
Rubinは、HASH160ダイジェストへの署名の意味をさらに探求し、量子コンピュータがECDSAを破ったとしても、それは秘密鍵の漏洩にとどまり、実際の署名内容の能力を変えるわけではないと説明した。この点について暗号学者Madars Virzaに相談したところ、肯定的な回答を得た。
Rubinは指摘する。もしECDSA署名に量子耐性のある署名アルゴリズムによる署名を要求すれば、量子耐性を持つビットコインが実現できる。そして前述の5バイト署名方式は、実は量子安全なLamport署名の一種である。しかし残念ながら、この方法では少なくとも20バイトの連続した領域が必要となる。
そこでRubinは、何らかのOP_CAT類似のオペコードが必要になると提案。記事では、Segwit v0にOP_CATを直接ソフトフォークすることは不可能だと説明。なぜならスタックを変更してしまうためだ。そこで簡略化のため、新しいオペコードOP_SUBSTRINGEQUALVERIFYの使用方法を示した。これは意味論的に文字列の一部が等しいかどうかを検証するものである。
2021年11月5日、アトランタで開催されたビットコインカンファレンスで、Jeremy RubinとAndrew Poelstraがスピーカーとして、OP_CATオペコードの再導入に関する提案について議論した。彼らはOP_CATがビットコインの文脈で重要であるとし、特に量子安全性や複雑なスマートコントラクト作成における可能性を強調した。例えば、CATとSchnorr署名検証オペコードを組み合わせることで、理論的には非再帰的なスマートコントラクトが実現できる。このようなスマートコントラクトは、取引データのSHA2ハッシュを直接スタックに置くことができる。これにより、取引の各部分に一定の制限を課せるようになる。
議論では、CATを再導入すれば、ビットコインはある面で複雑化する一方で、新たな機能と可能性も生まれるとされた。OP_CATの再起動には過去の問題（例：メモリ爆発）を避けるために、慎重な検討が必要であるとされた。
2022年
2022年5月18日、ビットコイン開発者メーリングリストで、2010年に削除されたOP_CATオペコードの再導入に関する議論があり、開発者ZmnSCPxjが発言した。彼は、避けられない再帰的スマートコントラクトを実現するには、OP_CATをOP_TXやOP_CHECKSIGFROMSTACK（CSFS）などの提案オペコードと組み合わせる必要があると述べた。再帰的スマートコントラクトとは、ビットコインの合意ルールを利用して、コントラクトに受け取ったすべてのビットコインが、同じコントラクト上でのみ使えるようにするものだ。
再帰的スマートコントラクトは「取引内省（transaction introspection）」技術に依存する。つまり、オペコードが自身を実行している取引の一部を分析できるようにする。現在のオペコードは、限定的な内省しか提供していない。再帰的スマートコントラクトを作成するには、前の出力と次の出力が同一であることを保証する必要がある。そのため、前の出力、あるいは次の出力、あるいは両方を構成要素から動的に構築する必要があり、これがCATや類似構造が必要な理由である。
Nadav Ivgiは、再帰的スマートコントラクトの作成時には依然としてCATが必要だと指摘。しかし同時に、出力内省に焦点を当てるCTVやAPOなどの機能も、CATと組み合わせることで再帰的スマートコントラクトを構築できると述べた。Ivgiは、taprootの機能と併用することで、次の出力を用いて前の出力を検証できるようになり、スマートコントラクトスクリプトの記述が容易になるとし、2つの再帰的スマートコントラクトの例のリンクを提示した。
ZmnSCPxjはIvgiの分析に同意し、ビットコイン上で再帰的スマートコントラクトを有効化することへのリスクへの懸念を改めて表明した。ただし、後続の投稿では、再帰的スマートコントラクトはチューリング完全ではないため、理論的には安全である可能性もあると指摘。Russell O'ConnorはAndrew Poelstraの記事を引用し、CAT自体が既存のビットコイン機能と組み合わさることで非再帰的スマートコントラクトの作成に十分だとし、理論的には再導入されれば単体でも再帰的スマートコントラクトが可能になると述べた。
2023年
1月、Anthony TownsがBitcoin Inquisitionを立ち上げた。これはBitcoin Coreを模したソフトウェアで、デフォルトのsignet上で動作し、人々が提案するソフトフォークや主要なプロトコル変更のテストを目的としている。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がビットコインスクリプト言語の変更による汎用スマートコントラクトについて研究を行った。同時に極めて重要なことに、Ethan HeilmanとArmin Sabouriが共同でOP_CATオペコード追加のBIP草案を発表。このオペコードはスタック上の2要素を連結するものである。これら2つのテーマに関する議論は11月まで続いた。
2024年
2024年1月、Quantum Catsは確かに、OP_CATに関するBIPおよびビットコインプロセスの議論を新たな高みへと押し上げた。
コミュニティとの交流の中で、Bitcoin Core開発者のAva Chowは次のように述べた。「私はCTVが緩やかな合意（rough consensus）だとは思わない。実際、txhashやCATのような他のより一般的なスマートコントラクト提案の方がそれに近いと思う。ただ、私は議論をあまり注意深く追いかけていない。」
提出回数でソートすると、現時点でAva Chow（@achow101）はBitcoin Coreのコード貢献者ランキングで5位に位置し、コードのコミット回数は1292回に達している。ビットコインコードのマージ権を持つ数少ない人物の一人でもあり、開発コミュニティ内での影響力は非常に大きい。
「私はOP_CATのアクティベーションを提案しているわけではない。私はOP_CATを支持している。なぜなら、これは合意に達しうる可能性が高いオペコードだからだ。OP_CATの状況を理解していない人のために、この画像で要約してみた。」――Taproot Wizard共同創業者のEric Wall（@ercwl）の発言である。
ただし、Ava ChowはOP_CATの実装に対して絶対的な賛同を示していない。「繰り返すが、私はどのスマートコントラクト提案も、緩やかな合意に近づいているとは思わない。そのような提案のいずれかをアクティベートしようとするべきではないと考えている。」
10行のコードでビットコインにスマートコントラクトを実現
Taproot Wizard共同創業者のEric Wall（@ercwl）が述べたように、「人々は気づいていないが、OP_CATは実際にはビットコイン上でのzkrollupの構成要素の一つなのだ。」
OP_CATの再導入は、ビットコインに強力なツールを提供する。これによりBitVMのようなプロジェクトが支援される。BitVMが最近提唱した「ビットコイン上で任意の計算を検証する」という概念は、OP_CATによりさらに簡素かつ効率的になる。ビットコインエコシステムは、より汎用的で表現力豊かなスマートコントラクトを構築できるようになる。
OP_CATにより、特定のビットコイン出力に対して事前に規定された条件を設定する「スマートコントラクト」が実現できる。これはBlockstreamのArkのような新たな拡張手法への扉を開くだけでなく、スマートコントラクトに依存する多くの他の革新的なアプローチを支援する。さらにこれは、ビットコインが単なる決済ネットワークではなく、多機能かつ拡張可能な計算プラットフォームになりうることを示している。
WallはBitVMの背後にある概念に興奮しているが、その提案はオーバーヘッドが大きく実装期間も長いことから、ビットコインの「技術的死胡同（dead end）」になる可能性があると考えている。BitVMがコミュニティの注目をそらし、真の発展を妨げる恐れがあると懸念している。とはいえ、BitVMの提案自体が、ブロックチェーン技術とスマートコントラクト分野における活発な探求と革新精神を示している。
実際、Taproot Wizardプロジェクトチーム自身も、ビットコイン上でレイヤー2ソリューションを実現しようとしている。以前のSpaceで、調達した750万ドルの資金はビットコインのスケーリングソリューションの研究に使われると明言している。
したがって、OP_CATのソフトフォークは彼らにとっても重要な一歩となる。Eric WallはかつてStarkNet財団の理事を務めており、許可不要の決済層上でDeFiを構築することに強い関心を持っている。2019年にイーサリアムが登場した際、自然とそのDeFi分野に惹かれた。
2019年に、イーサリアムや他のブロックチェーンがzk-Rollupsや楽観的詐欺証明を使ってスケーリングできることが明らかになったとき、ビットコインにおけるDeFiの探求はほぼ完全に放棄されていた。Wallは「zk-Rollupのスケーリングをビットコインに適用できるか」という疑問を持ちながらも、一時的にイーサリアムのDeFiを支持する方向に舵を切った。しかし最終的に、彼はそのシステムと技術的利点をビットコインに持ち込もうと努力している。
また、bitcointalkフォーラムでのOP_CATに関するスレッドで、QEDプロジェクトの創設者Carter Feldman（@cmpeq）に、ビットコインスクリプトでこのオペコードをどう活用するつもりか、また証人スタックの平均バイト数や発生する費用を計算したかと尋ねられた。
Feldmanはコストがやや高くなる可能性を認識しているとしながらも、説明した。彼のプロジェクトでは、Merkle証明は主に信頼不要のロックスクリプトやホッキングシステムの構築に使われ、これはビットコイン上でのzkレイヤー2の一部となる。このシステムは、与えられた出金ツリールート（ゼロ知識証明の公開入力）のもとで、特定のアドレスに出金できるビットコインの量を証明することを目的としている。
コスト問題を解決する手段として、彼は次のように述べた。一般ユーザーは、L2上でwBTCの売り手が一定期間代金をロックすることでL2上のwBTCを購入できる。この期間中、買い手はL1ビットコイン上で売り手に支払い済みであることを証明しなければならない。彼らは、必要であればいつでも信頼不要でビットコインに戻せることを知っている。一方、数社の大規模流動性プロバイダーが、実際のwBTCとBTCの交換を担い、小型ユーザーがwBTCを購入したりビットコインに橋渡ししたりする際に少額の手数料を請求する可能性がある。
総じて、今回のOP_CATのBIP提案はわずか13行のコードでビットコイン上でのスマートコントラクト構築を可能にするが、個々のプロジェクトごとの詳細な処理については、今後も多くの議論と試行が行われるだろう。
ミーム文化が技術進展を後押し
TaprootWizardsチームメンバーのRijndael（@rot13maxi）は、SNSでアート制作のために使用したさまざまな複雑な仕組みを共有した。この目標を達成するため、序数の再帰、事前署名取引、対称暗号、クライアント負荷管理など、複数の技術を活用している。アート制作プロセスでは、特に事前署名取引を使用してOP_CATやCTVなどのスマートコントラクトで取引ハッシュを事前にコミットする方法を実演している。
しかし、Armin Sabouriは皮肉交じりのコメントを残した。「進化するNFTコレクションを作成するために投入されたコードや技術的努力は、あるオペコードを再有効化するのに必要な作業量の100倍にもなるかもしれない。」
OP_CATは単純で理解しやすいオペコードとされ、「ECDSA署名に署名することでビットコインを『量子安全』にできる」とする見方も一部に存在する。この見解は支持され、Taproot WizardがQuantum Cats（量子猫）NFTキャンペーンを展開するきっかけとなり、OP_CATへの認知度向上に貢献した。
しかし、技術進展のためにミーム文化を活用するのは、OP_CATだけではない。
Quantum Catsとその0.1BTCという高価格に触発され、あるいはその高額販売に対する不満の一部からか、OP_CTVコミュニティも「#rubinsreubens」というサンドイッチミームを立ち上げ、OP_CTVの技術を宣伝した。
このサンドイッチミームは当初、量子猫やそのミームに対するユーモラスな反応として始まった。しかし実際には非常に効果的だった。CTVと同じく、これは階層を追加するものであり、「サンドイッチ」に必要なだけ任意の数の層を追加できる。
このサンドイッチミームは多くの人々の注目を集めた。ミームは面白いだけでなく、何かに対する支持を示す手段にもなるが、その背後にある意味を理解することも重要だ。#rubinsreubensの目的は、op_ctv、lnhance、および新しいBTCオペコードやスマートコントラクト有効化のソフトフォーク提案への理解を高めることにある。
TechFlow公式コミュニティへようこそ Telegram購読グループ：https://t.me/TechFlowDaily Twitter公式アカウント：https://x.com/TechFlowPost Twitter英語アカウント：https://x.com/BlockFlow_News
BlockBeats関連記事
ある外国人から見た智譜 AI：モデル無料、巨額の赤字、時価総額なぜ一時美団を超えたのか？
清華大学の血統、国有資本の裏付け、売上の 73.7% が国有企業へのプライベートデプロイメントに由来する点、これこそが智譜が本当に売っているものだ。
Ondo Perps 検証：米国株を証拠金に、米国株・金・原油を 20 倍ロング/ショート
「買える」から「使いこなせる」へ、「オンチェーンで米国株を取引する」というストーリーの後半は、Ondo Perps によって展開されつつある。
ADI の隠れた勝利：伝統的な金融エコシステムのインフラ青写真
ADI Chain はまず、現実世界の金融ですでに存在する資金、資産、取引フローをチェーン上に接続し、その後、これらの流動が逆に$ADI のユースケースを裏付けることを目指しています。
A株式市場ではストレージチップが注目されており、ウォールストリートでは分散型ストレージについて議論されている。
AIストレージ能力という兆ドル規模の主要テーマにおいて、FILこそがWeb3の純正銘柄である。
OpenRouter：「モデル中継ステーション」を活用して、どうすれば10億ドル規模の企業を実現できるのか？
OpenRouter が真に重要な能力は、モデルとプロバイダー間のスケジューリングを行うことです。
アーサー・ヘイズ氏（ファミリーオフィス研究部門責任者）：$CARDSは夏季に4米ドルまで上昇すると予想。ブロックチェーン上のカード取引事業の勢いは、eBayを上回る可能性がある。
Collector Crypt（CC）は、Solana上で評価付きトレーディングカードをトークン化し、ガチャメカニズムと二次市場を活用して高収益モデルを構築しています。6月の年率換算利益は約1億900万ドルに達しており、実際の価値よりも大幅に低い評価額で急速に成長しています。これは、eBayを凌駕する可能性を持つ、ブロックチェーン上のコレクターズアイテム向け金融インフラとなることが期待されています。
SpaceX はなぜこれほど高い評価額の上限を有しているのか？その答えは、マスク氏のビジネス版図に隠されている。
スペースXによるこの資本の祭典は、新たなサイクルの始まりを意味する可能性があり、より深いレベルでのテクノロジー産業の競争は、まさに今幕を開けたばかりです。
CEXにおけるAI軍拡競争：エントリーポイントか、基盤インフラか——どちらのソリューションがあなたに最適ですか？
あなたがどのようなユーザーであるかによって、より適した道が決まります。
a16z：太陽が証人だ、SpaceX の価値は7.5兆ドル
マスク氏の究極のロードマップを深層分析
Anthropicの三重の瞬間：コード漏洩、政府との対立、および兵器化
この「安全性」を売りにしている企業は、安全性というストーリーをビジネス上の護城河へと変貌させようとしており、実際にはマイクロソフトなどの企業が保有するユーザー・データを奪おうとしている。
