ビットコイン開発者対インスクリプション：長年にわたる対立
TechFlow厳選深潮セレクト
ビットコイン開発者対インスクリプション：長年にわたる対立
Bitcoin Coreの開発者たちは長くインスクリプションに反対しており、明確な対応を取る意向を示している。しかし、インスクリプション市場はすでにマイナー、取引所、ユーザーといった各方面の利害が絡み合っており、複数の勢力間で綱引きが続く構図となっているため、進展は順調にはいかないだろう。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Trustless Labs
本日、Bitcoin Core 開発者の Luke が X プラットフォーム上で Ordinals 類のインスクリプション（銘文）プロトコルに反対する立場を表明し、これをビットコインに対する攻撃と見なしている。彼は、インスクリプションがビットコインの脆弱性を悪用してネットワークにスパム情報を大量に投稿していると批判した。
この発言は直ちに Bitcoin コミュニティ内で拡散され、大きな注目と議論を呼んだ。
論争の起源
実際、Bitcoin Core 開発者によるインスクリプションへの疑義は以前から存在していた。セグウィット導入後、ブロックサイズ上限は 4MB に拡大されたが、今年2月に採掘されたブロックのサイズは 3.96MB に達し、そのうち Ordinals 関連の取引が 3.94MB を占め、驚異的な 99.5％ を記録した。5月にインスクリプションが急激に流行し始めた段階で、Bitcoin-dev 内では非標準の Taproot 取引が多数のブロックスペースを占有していることに対し懸念が示された。 dev-emailでは、BRC-20 類似のプロジェクトが膨大な取引量を生み出し、BTC ネットワークが深刻な混雑状態となり、「本物のビットコイン取引（real Bitcoin transaction）」が正常にブロックに取り込まれなくなっていることが指摘された。
Luke は、Ordinals 類のプロトコルを「価値がない（worthless）」と断じ、それが BTC をピアツーピア暗号通貨としての本来の用途に深刻な影響を与えていると述べた。また、メールでも今回ツイートで言及したインスクリプション制限方法について触れており、クライアント側に審査メカニズムを追加してノードが非標準の Taproot 取引を強制的に削除し、リレーしないようにすることで、インスクリプション行為を阻止しようとするものである。
アップグレード案およびその影響
Luke のツイートによると、提案されている制限措置は主に Knots クライアントにおけるポリシー設定に関するものだ：
-datacarriersize：
-
このパラメータは OP_RETURN 出力スクリプトに埋め込めるデータ量を制限するものであり、これらのデータは UTXO の出力に含まれる。既存のプロトコルでは、Omni や Colored が OP_RETURN にデータを挿入して動作しており、インスクリプションエコシステム内の Runes も同様に OP_RETURN を利用してデータ索引を提供している。
-
現在のデフォルト値は 83 バイトだが、Luke は現行クライアントでこれを直接 0 に設定し、OP_RETURN データを含む取引のリレーを禁止することを提案している。また、次期リリース予定の Knots 25.1 ではこのパラメータのデフォルト値を 42 に変更する予定である。
-maxscriptsize：
-
このパラメータはノードがリレー可能な取引のスクリプトサイズを制限するもので、Ordinals プロトコルは Taproot スクリプト内にプロトコルデータを刻み込むことでデータ索引を提供している。
-
このパラメータが有効化されれば、P2P ノードは設定されたしきい値を超える Taproot スクリプトサイズを持つ取引をリレーしなくなり、Ordinals のミントや譲渡に影響が出る。
-
Luke は V25.1 でこのパラメータを導入し、デフォルト値を 1650 に設定した。
今回の Luke のアップグレード方針は、Bitcoin-dev のメールで言及したクライアントにフィルターを追加して非標準 Taproot 取引を除外する考えと一致している。マイナーたちがこのコード変更を採用すれば、ノードは script size が設定値（デフォルト 1650 バイト）を超える Taproot 取引のリレーを拒否し、一部の Ordinals 取引は正常に放送できなくなるだろう。
ただし、今回の更新は Knots クライアントにおいて OP_RETURN および TaprootScript が運ぶデータサイズを制限するものに過ぎず、ノード運営者にインスクリプション関連取引の受信拒否を選択できる権限を与えるにとどまり、根本的にノードのリレーやマイナーによるブロック採用を阻止することはできない。さらに、Bitcoin Core における Taproot アップグレードでは、Taproot witness データのサイズに対して相応の検証が設けられていない。
コード上での判断から、現行 Knots バージョンの最大値 1650 バイトはトークン転送の要件を満たすことができるため、現行の制限方式では BRC-20 関連操作を完全に阻止することはできない。さらなる制限については、今後の Luke によるポリシー変更を注視する必要がある。
BTC エコシステムの今後
インスクリプションを巡る論争は長く続いているが、今日の異常に活況を呈する BTC エコシステムにおいて、Luke の発言はコミュニティに大きな衝撃を与え、BTC エコシステムの将来についての熱烈な議論が巻き起こっている。
この出来事に関して、マイナー代表の神魚も自身の見解を示しており、「ビットコインは開発者が主導するものではなく、マイナーが対応するアップグレードを支持すべきであり、そうでなければ開発者自身がフォークするしかない」と述べた。
また、Luke が提唱する「ゴミ取引」とされるインスクリプションの審査・フィルタリングは、現時点ではクライアントレベルに留まっており、プロトコルレベルでインスクリプション取引を完全に禁止するには、Bitcoin Core へのコード統合が必要となる。場合によっては BIP の形で正式に導入しなければならず、Luke 自身も V27 アップグレードまではこの「脆弱性」を回避できないと認めている。
コミュニティの複数の KOL もこの問題について発言しており、「絶対に承認しない」という声もある：
漫霧余弦も「修正する必要はない」と述べている：
こうした意見から、コミュニティがインスクリプションエコシステムを依然として前向きに捉え、それが BTC エコシステムおよびマイニングにもたらした巨大な発展動力を認めていることがうかがえる。また、Layer2 的な「インスクリプションチェーン」を構築するというアイデアに対しても、Luke は肯定的な返答をしている。
以上のように、今回の議論は広範囲にわたり、Bitcoin Core 開発者たちがインスクリプションに長年反対し、明確な行動を取ろうとしているものの、インスクリプション市場がすでにマイナー、取引所、ユーザーの利害関係と深く結びついていることを考えれば、その進展は決してスムーズにはいかないだろう。一方、常に「正統派」と見なされてきた Taproot Asset はオンチェーンスペースの使用量が少ないため、アップグレード後も影響を受けにくく、この分野はさらなる可能性を引き出すかもしれない。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@TrustlessLabs
