BTCエコシステムのスケーリングソリューション巡礼：インスクリプションの行方とは？
TechFlow厳選深潮セレクト
BTCエコシステムのスケーリングソリューション巡礼：インスクリプションの行方とは？
人気のあるインスクリプションエコシステムの技術原理と、それに関連して発生し得るセキュリティ上の問題を探る。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Simon shieh
序論
2023年12月6日、ビットコイン投資家たちがインスクリプション（Inscriptions）による価格上昇に沸く中、Bitcoin Coreノードクライアントの開発者Luke Dashjrは冷水を浴びせた。彼はインスクリプションを一種の「スパム」攻撃と見なし、修正コードとCVE脆弱性報告（CVE-2023-50428）を提出した。その後、ビットコインコミュニティは再び激しい議論に包まれることになった。これは2017年のハードフォーク騒動以来の大規模な論争である。
ではビットコインは安全性を重視して予期しない機能を捨てるべきか、それとも予期しない革新をより包容し、若干のセキュリティリスクを許容すべきだろうか？
我々は知っている。ビットコインの旅路は投機や話題作りだけではなく、そのエコシステムとセキュリティ体制の継続的な進化の過程でもある。本稿では、ビットコイン成長の二重の物語——すなわち、エコシステム内での実用性の拡大とセキュリティ対策の強化——について深く探求する。イノベーションと堅牢なセキュリティプロトコルの相乗効果が、デジタル資産の新しい時代をどのように切り開いているのかを明らかにする。
1 BTCエコシステム概観および基礎知識
暗号通貨革命の基盤として、ビットコインは長年にわたりゴールドのような価値保存手段とされてきた。他のパブリックチェーンでDeFiの革新が盛んに行われる中、人々はついビットコインの存在を忘れがちである。
しかし実は、安定通貨（ステーブルコイン）、Layer2、さらにはDeFiの実験が最初に始まったのはビットコイン上だった。現在の暗号通貨界の硬通貨であるUSDTも、当初はビットコインのOmniLayerネットワーク上で発行された。下図は技術的実装の観点から見たビットコインエコシステムの基本分類である。
これには、双方向アンカー型サイドチェーン、出力スクリプト（OP_RETURN）によるテキスト解析、Taprootスクリプトによる刻印、BIP300アップグレードに基づくドライブチェーン、ステートチャネルに基づくライトニングネットワークなどの技術が含まれる。
上記の多くの用語にまだ馴染みがない読者も多いだろう。心配いらない。まず以下の基礎知識を理解し、その後これらのエコシステムの技術原理とそこに潜むセキュリティ問題について一つずつ解説していく。
UTXOはビットコイン取引の基本単位
イーサリアムのアカウント残高モデルとは異なり、ビットコインのシステムには「アカウント」という概念はない。イーサリアムは4つの複雑なMerkle Patricia Trieを導入してアカウント状態の変化を記録・検証している。一方、ビットコインはUTXO（未使用取引出力）を巧みに利用することで、より簡潔にこれらの問題を解決している。
イーサリアムの4つのツリー
ビットコインの入力と出力
UTXO（Unspent Transaction Outputs：未使用取引出力）という名称は一見難しく聞こえるが、入力、出力、取引という3つの概念を理解すれば簡単に理解できる。
取引の入力と出力
イーサリアムに詳しい方はご存じだろうが、取引（transaction）はブロックチェーンネットワークにおける基本的な通信単位であり、取引がブロックに取り込まれて確定すると、チェーン上の状態変更が確定する。一方、ビットコインの取引では、単純なアドレス間の状態操作ではなく、複数の入力スクリプトと出力スクリプトによって構成される。
上図は典型的なビットコインの2対2取引の例である。理論的には、入力されたBTC数量と出力されたBTC数量は等しくなければならないが、実際には出力額の方が少なく、その差額がマイナーの手数料として採掘者に支払われる。これはイーサリアムにおけるGas Feeに相当する。
この図では、2つの入力アドレスがBTCを移転する際に、入力スクリプト内で検証を行い、これらの入力アドレスが当該入力（つまり前回取引の未使用出力、UTXO）を使用できることを証明している。一方、出力スクリプトでは、次回にこの未使用出力を入力として使う際に満たすべき条件（通常は受取アドレスの署名。例えば上図ではP2wPKHはtaprootアドレスの署名検証を意味し、P2PKHはlegacyアドレスの秘密鍵署名を意味する）を規定している。
具体的には、ビットコイン取引のデータ構造は以下の通りである：
ビットコイン取引の基本構造は2つの主要部分からなる：入力と出力。入力部分は取引の送信元を示し、出力部分は受取先とお釣り（存在する場合）を示す。取引手数料は入力合計額と出力合計額の差額である。各取引の入力は過去の何らかの取引の出力であるため、取引の出力こそが取引構造の中心要素となる。
このような構造により、鎖状の接続が形成される。ビットコインネットワークでは、すべての正当な取引は一つまたは複数の過去の取引出力に遡ることができる。これらの取引鎖の起点はマイニング報酬であり、終点は現在まだ使用されていない取引出力である。ネットワーク内のすべての未使用出力の集合を、ビットコインネットワークのUTXO（Unspent Transaction Output）と呼ぶ。
ビットコインネットワークでは、すべての新規取引の入力は未使用出力でなければならない。さらに、各入力には、前の出力に対応する秘密鍵による署名が必要である。ビットコインネットワークの各ノードは、現在のブロックチェーン上のすべてのUTXOを保持しており、これにより新規取引の正当性を検証する。UTXOと署名検証メカニズムを通じて、ノードは取引履歴全体を遡らずに新規取引の正当性を検証でき、ネットワークの運用と保守を簡素化している。
ビットコイン独特の取引構造は、白書『Bitcoin: A Peer-to-Peer Electronic Cash System』の設計思想に合致している。ビットコインは電子現金システムであり、その取引構造は現金取引のプロセスを模倣している。あるアドレスで使用可能な金額は、以前に受け取った現金の量に依存する。各取引では、そのアドレス上のすべての現金を一度に使い切る必要があり、出力先アドレスは通常、受取アドレスとお釀りアドレスの2つになる。これはスーパーで現金で買い物をする際のお釈りと同じである。
スクリプト
ビットコインネットワークにおいて、スクリプトは極めて重要な役割を果たしている。実際、ビットコイン取引の各出力は特定のアドレスではなく、実際にはスクリプトを指している。これらのスクリプトは一連のルールのように、受取人が出力でロックされた資産を使用するために満たすべき条件を定義している。
取引の正当性検証は2種類のスクリプトに依存している：ロックスクリプトとアンロックスクリプト。ロックスクリプトは取引の出力に存在し、その出力をアンロックするために必要な条件を定義する。アンロックスクリプトはこれに対応し、UTXO資産をアンロックするためにロックスクリプトで定義されたルールに従っていなければならない。アンロックスクリプトは取引の入力部分に位置する。このスクリプト言語の柔軟性により、ビットコインは多様な条件の組み合わせを実現でき、「部分的にプログラマブルな通貨」としての特性を示している。
ビットコインネットワークでは、各ノードがスタックベースのインタプリタを実行しており、「後入れ先出し」（LIFO）の原則に基づいてこれらのスクリプトを解釈している。
最も代表的なビットコインスクリプトには主に2種類がある：P2PKH（Pay-to-Public-Key-Hash）とP2SH（Pay-to-Script-Hash）。P2PKHはシンプルな取引タイプで、受取人は対応する秘密鍵で署名するだけで資産を使用できる。P2SHはより複雑で、例えばマルチシグの場合は複数の秘密鍵の組み合わせ署名が必要となる。
こうしたスクリプトと検証メカニズムが共同でビットコインネットワークの核心的運営方式を構成し、取引の安全性と柔軟性を確保している。
例えばビットコインにおけるP2PKHの出力スクリプトのルールは以下の通り：
公開鍵スクリプト: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
入力側は署名を提供する必要がある
署名スクリプト: sig
またP2SHの出力スクリプトのルールは以下の通り：
公開鍵スクリプト: OP_HASH160 OP_EQUAL
入力側はマルチシグリストを提供する必要がある
署名スクリプト: [sig] [sig...]
上記2種類のスクリプトルールにおいて、Pubkey script はロックスクリプトを表し、Signature script はアンロックスクリプトを表している。OP_で始まる語は関連するスクリプト命令であり、ノードが解釈可能な指令である。これらの命令ルールはPubkey scriptの種類に応じて区別され、アンロックスクリプトのルールも決定づける。
ビットコインのスクリプト機構は比較的単純で、スタックベースのエンジンであり、関連するOP命令を解釈するもので、扱えるスクリプトルールは多くなく、複雑なロジックを実現できない。しかしブロックチェーンのプログラマビリティの原型を提供しており、後続のいくつかのエコシステムプロジェクトは実際にはこのスクリプトの原理に基づいて発展してきた。隔離ウィットネス（SegWit）やTaprootのアップデートとともに、OP命令の種類はさらに豊かになり、各取引に含まれるスクリプトのサイズも拡張され、ビットコインエコシステムは爆発的な成長を迎えた。
2 インスクリプションの技術原理とセキュリティ問題
インスクリプション技術の流行は、ビットコインの隔離ウィットネス（SegWit）とTaprootのアップデートに大きく依存している。
技術的に見ると、ブロックチェーンの非中央集権性が高いほど、通常その効率は低くなる傾向にある。ビットコインの場合、各ブロックのサイズは依然として1MBに保たれており、中本聡が最初に採掘したブロックと同じ大きさである。スケーリングの課題に対して、ビットコインコミュニティは単純にブロックサイズを増やすという道を選ばなかった。代わりに、「隔離ウィットネス」（Segregated Witness、略称SegWit）という方法を採用した。これはハードフォークを伴わないアップグレード案で、ブロック内のデータ構造を最適化することでネットワークの処理能力と効率を向上させることを目指している。
隔離ウィットネス（SegWit）
ビットコイン取引では、各取引の情報は主に2つの部分に分けられる：基本取引データとウィットネスデータ。基本取引データには口座残高などの重要な財務情報が含まれ、ウィットネスデータはユーザーの身元確認に使用される。ユーザーにとって、彼らが関心を持つのは資産に関連する情報（例：口座残高）であり、身元検証の詳細は取引内で多くのリソースを消費すべきではない。言い換えれば、資産を受け取る側は資産の可用性に注目するだけであり、送信者の詳細情報を過度に気にする必要はない。
しかしビットコインの取引構造では、ウィットネスデータ（すなわち署名情報）が大量のストレージスペースを占めているため、送金効率の低下や取引手数料の増加が生じている。この問題を解決するため、隔離ウィットネス（SegWit）技術が導入された。その核心アイデアは、ウィットネスデータを主要な取引データから分離し、別途保存することである。これによりストレージの使用効率が最適化され、取引効率の向上とコスト削減が実現される。
この結果、既存の1MBブロックサイズを変えずに、各ブロックがより多くの取引を収容できるようになる。隔離されたウィットネスデータ（つまり各種署名スクリプト）は追加の3MB空間を使用でき、Taprootスクリプト命令の拡充にストレージ基盤を提供する。
Taproot
Taprootはビットコインネットワークにおける重要なソフトフォークアップグレードであり、ビットコインスクリプトの秘匿性、効率性、およびスマートコントラクト処理能力の向上を目的としている。このアップグレードは2017年のSegWitアップグレード以来の最大の進歩と見なされている。
このTaprootアップグレードには3つの異なるビットコイン改善提案（BIP）が含まれる：Taproot（MAST：Merkelized Abstract Syntax Trees）、Tapscript、そしてマルチシグに適した新たなデジタル署名スキーム「Schnorr署名」である。Taprootの目的は、ビットコインユーザーに秘匿性の向上、取引コストの削減といったメリットを提供することにある。さらに、より複雑な取引を実行する能力を強化し、応用範囲を拡大することも目指している。
Taprootのアップグレードは直接的に3つのエコシステムに影響を与える。1つはOrdinalsプロトコルで、Taprootのscript-path spend scriptsを利用して付加データを実現する。2つ目はライトニングネットワークのTaproot Assetへのアップグレードで、単純なポイントツーポイントBTC決済から、マルチポイント対応かつ新たな資産発行をサポートする形へと進化する。3つ目は新たに提案されたBitVMで、Taprootのop_boolandおよびop_notを利用してブール回路をTaprootスクリプトに「エッチング」し、スマートコントラクト仮想マシンの機能を実現する。
Ordinals
OrdinalsはCasey Rodarmor氏が2022年12月に発明したプロトコルで、各サトシ（Satoshi）に固有のシリアル番号を付与し、取引の中でそれらを追跡できるようにする。誰でもOrdinalsを使ってUTXOのTaprootスクリプトにテキスト、画像、動画などの追加データを添付できる。
Ordinalsに詳しい方ならご存じだろうが、ビットコインの総供給量は2100万枚、1ビットコインは10^8のサトシ（sats）から成るため、ネットワーク上には2100万×10^8個のサトシが存在する。Ordinalsプロトコルはこれらサトシを区別し、それぞれに一意の番号を割り当てる。理論的には可能だが、実際には不可能である。
なぜなら、BTCネットワークはダスト攻撃を防ぐために送金に最低546サトシ（segwitでは最低294サトシ）の制限があり、1サトシ単位での送金はできない。アドレスの種類に応じて、少なくとも546サトシまたは294サトシを送金しなければならない。OrdinalsのFIFO（先入れ先出し）番号理論によれば、各ブロックの1番～294番のサトシは分割不能である。
つまり「刻印」とは、特定のサトシに直接行うのではなく、少なくとも294サトシの送金を含む取引のスクリプトに記録されるものであり、その後、UniSatのような中心化インデクサーがその294サトシまたは546サトシの移動を追跡・識別している。
取引中のインスクリプションの符号化方式
原則としてTaprootスクリプトの使用は既存のTaproot出力からのみ可能であるため、インスクリプションは理論的には「コミット／リベール（提示）」の2段階プロセスで行われるべきである。まずコミット取引で、script path spendに基づく内容のTaproot入力を生成し、出力で使用／リベールの署名条件を明示する。次に、リベール取引で、コミット取引によって生成された出力が使用され、チェーン上にインスクリプションの内容が明らかになる。
しかし実際のインデクサー環境では、リベール取引の役割にあまり注目せず、直接入力スクリプト内のOP_FALSE OP_IF ... OP_ENDIFで構成されるスクリプト断片を読み取り、そこからインスクリプションの内容を抽出している。
OP_FALSE OP_IFの命令組み合わせはそのスクリプト断片が実行されないことを意味するため、本来のスクリプトロジックに影響を与えることなく任意のバイト列を格納できる。
文字列「Hello, world!」を含むテキストインスクリプションは以下のように直列化される：
OP_FALSE OP_IF OP_PUSH "ord" OP_1 OP_PUSH
"text/plain;charset=utf-8" OP_0 OP_PUSH "Hello, world!" OP_ENDIF
要するに、Ordinalsプロトコルはこのコード断片をTaprootスクリプトに直列化している。
実際にブロックチェーン上の取引を調べて、Ordinalsの符号化原理を詳しく説明しよう：
https://explorer.btc.com/btc/transaction/885d037ed114012864c031ed5ed8bbf5f95b95e1ef6469a808e9c08c4808e3ae
この取引の詳細情報を確認できる：
Witnessフィールドの0063（OP_FALSE OP_IF）から始まる符号化を分析することで、直列化された内容を理解できる：
つまり、このウィットネススクリプト内の該当部分のコードをデコードできれば、刻印された内容がわかる。ここではプレーンテキスト情報が符号化されているが、HTML、画像、動画など他のデータも同様の方法で符号化される。
理論的には独自の符号化内容、あるいは自分だけが知る暗号化内容を定義することも可能だが、そのような内容はOrdinalsブラウザでは表示されない。
BRC20
2023年3月9日、匿名のTwitterユーザーdomo氏が、Ordinals Protocolの上に同質性トークン標準を構築する提案を投稿し、それをBRC20標準と呼んだ。このアイデアは、Ordinalsプロトコルを通じてJSON文字列データをTaprootスクリプトに刻印することで、同質性BRC-20トークンの展開、発行、転送を可能にするものである。
図1：BRC-20トークンの謙虚な始まり（domo氏による最初の投稿）
出典：Twitter（@domodata）
図2：BRC-20トークンが想定する3つの初期操作（p = プロトコル名、op = 操作、tick = 銘柄コード／識別子、max = 最大供給量、lim = 発行制限、amt = 数量）
出典：https://domo-2.gitbook.io/brc-20-experiment/、Binance Research
トークン発行者はdeployによりBRC20トークンをブロックチェーン上に展開し、参加者はmintによりほぼゼロコスト（マイナー手数料のみ）でトークンを取得できる。mint数量がmaxを超えると、その以降のmintインスクリプションはインデクサーによって無効と判断される。その後、トークンを保有するアドレスはtransferインスクリプションによりトークンを移転できる。
注目に値するのは、Ordinalsの創設者Casey氏が、BRC-20取引がOrdinalsプロトコルの大部分を占めることに不快感を示している点である。彼は公に、BRC-20が自身が創造したOrdinalsに不要なゴミを大量に持ち込んだと述べた。そのため、Caseyチームはビナンスに対し、ORDIトークン紹介ページから「Ordinals」の記載を削除するよう要請した。彼はOrdinalsプロトコルとORDIトークンとの関係を否定したいのだ。
拡張プロトコル
BRC20 swap
現在、インスクリプション取引最大の市場であり、インデクサーやウォレット供給元でもあるUniSatは、BRC20取引向けにBRC20 swapプロトコルを提案しており、すでに早期ユーザーによる試用が可能になっている。
従来のインスクリプション取引は、PSBT（Partial Signed Bitcoin Transaction）という方式でのみ可能で、OpenSeaのオフチェーン署名スキームと同様、中心化サービスが売買両者の署名を「仲介」していた。これによりBRC20資産はNFT資産のように注文板方式でのみ取引可能となり、流動性と取引効率が非常に低かった。
BRC20 swapは、BRC20プロトコルのJSON文字列に「モジュール」と呼ばれる仕組みを導入する。このモジュール内にスマートコントラクトに類似したスクリプトを展開できる。例えばswapモジュールでは、ユーザーはtransferによりBRC20をモジュールにロック（自身への送金取引を行うが、インスクリプションはモジュール内にロックされる）し、取引完了またはLP撤退後に再度取引を発行することでBRC20トークンを引き出すことができる。
現在、BRC20 swapは「ブラックモジュール」の拡張モードで動作している。ブラックモジュールはセキュリティ上の配慮から、コンセンサスや検証なしに、モジュール内の資金総額に基づきユーザーが引き出せる金額を決定する。つまり、どのユーザーもモジュールにロックされた資産総額を超えて資産を引き出せない。
ブラックモジュールの挙動がユーザーに理解され、実行され、徐々に信頼され、より多くのインデクサーに受け入れられるようになると、製品はブラックモジュールからホワイトモジュールへと移行し、コンセンサスアップグレードが達成される。これによりユーザーは自由に資産の入出金ができるようになる。
さらに、BRC20プロトコル乃至Ordinalsエコシステム全体が依然初期段階にあるため、UniSatは大きな影響力と信頼を有しており、プロトコルに対して完全な取引・残高照会などのインデックスサービスを提供しているが、これには独占的な中央集権リスクがある。モジュール型アーキテクチャにより、より多くのサービスプロバイダーが参加できるようになり、インデックスの分散化が進む。
BRC420
Brc420プロトコルはRCSVによって開発された。彼らは既存のインスクリプションに再帰的インデックスの拡張を加え、より複雑な資産フォーマットを定義している。同時に、Brc420は単一のインスクリプションに基づき、使用権とロイヤルティの拘束関係を確立している。ユーザーが資産をmintする際には、作成者にロイヤルティを支払う必要があり、またインスクリプションを所有することでその使用権を分配し価格を設定できる。これによりOrdinalsエコシステムのさらなるイノベーションが促進される。
Brc420の提案はインスクリプションエコシステムに広大な想像空間を提供する。再帰的参照によりより複雑なメタバースを構築できるだけでなく、コードインスクリプションの再帰的参照を通じてスマートコントラクトエコシステムを構築することも可能になる。
ARC20
ARC20トークン標準はAtomicalsプロトコルによって提供される。この標準では、「原子（atom）」が基本単位であり、ビットコインの最小単位サトシ（sat）上に構築される。つまり、各ARC20トークンは常に1サトシによって裏付けられている。さらに、ARC20は初めて作業量証明（PoW）によるインスクリプション発行を実現したトークンプロトコルであり、参加者はビットコインを採掘するのと同様の方法で直接インスクリプションやNFTを「採掘」できる。
1つのARC20トークンを1サトシと同等にすることは、複数の利点をもたらす：
1. まず、各ARC20トークンの価値は決して1サトシを下回らないため、ビットコインはこの過程で一種の「デジタルゴールドのアンカー」としての役割を果たす。
2. 次に、取引検証時にはサトシに対応するUTXOを照会するだけでよく、BRC20がオフチェーン帳簿状態記録と第三者ソーターの複雑性を必要とするのと対照的である。
3. さらに、ARC20のすべての操作はビットコインネットワークを通じて完結でき、追加のステップは不要である。
4. 最後に、UTXOの合成可能性により、理論的にはARC20トークンとビットコインの直接交換が可能となり、将来の流動性に可能性を提供する。
Atomicalsプロトコルは、ARC20トークンの発行に特殊なプレフィックスパラメータ「Bitwork Mining」を設定している。トークン発行者は特殊なプレフィックスを選択でき、ユーザーはCPUマイニングで一致するプレフィックスを計算することにより、そのARC20トークンを発行する資格を得る。この「1CPU＝1票」のモデルはビットコイン正統派の理念に合致している。
インスクリプションは安全か
インスクリプションはあくまで「無害」なテキストをブロックチェーンに記録し、中心化インデクサーが解析しているように見えるため、セキュリティ問題は中心化サービスの範疇に限られると思われがちだが、オンチェーンセキュリティ面では以下の点に注意が必要である：
1. ノード負担の増加
インスクリプションはビットコインブロックのサイズを増加させ、ノードがネットワークでブロックを伝播・保存・検証する際に必要なリソースを増加させる。インスクリプションが過剰になると、ビットコインネットワークの非中央集権性が低下し、攻撃を受けやすくなる。
2. セキュリティの低下
インスクリプションは任意のデータ、悪意のあるコードを保存できる。悪意のあるコードがビットコインブロックに追加された場合、ネットワークのセキュリティ脆弱性を引き起こす可能性がある。
3. 取引の構築が必要
インスクリプション取引には取引の構築が必要であり、OrdinalsのFIFOルールに注意を払い、誤ってインスクリプションのインデックス順序が破壊されないよう注意しなければならない。
4. 买卖にリスクあり
インスクリプション取引市場はOTCであろうとPSBTであろうと、資産損失のリスクが存在する。
以下は具体的なセキュリティ問題の例である：
1. 孤立ブロック率とフォーク率の増加
インスクリプションはブロックサイズを増加させ、孤立ブロック率とフォーク率を上昇させる。孤立ブロックとは他のノードに承認されなかったブロックであり、フォークとはネットワーク内に複数の競合するブロックチェーンが存在する状態である。孤立ブロックとフォークはネットワークの安定性と安全性を低下させる。
2. 攻撃者によるインスクリプション改ざん
攻撃者はインスクリプションのオープン性を悪用して改ざん攻撃を行うことができる。
例えば、インスクリプションに格納された情報を悪意のあるコードに置き換えることで、インデクサーのサーバーに侵入したり、トロイの木馬でユーザー端末を感染させたりできる。
3. ウォレットの誤使用
ウォレットの使用方法が誤っている場合、ウォレットがインスクリプションをインデックスできない状況で、誤ってインスクリプション付きのUTXOを移転してしまう可能性があり、資産損失につながる。
4. フィッシングや詐欺
攻撃者は偽のUniSatなどのインデクサーWebサイトを用いて、ユーザーを誘導してインスクリプション取引を行わせ、資産を盗む可能性がある。
5. PSBT署名の漏れ
Atomicals Marketは誤った署名方法の使用により、ユーザーの資産に損害を与えたことがある。
関連記事：<The Analysis of the Atomicals Market User Asset Loss>https://metatrust.io/company/blogs/post/the-analysis-of-the-atomicals-market-user-asset-loss
これらのセキュリティ問題を解決するため、以下の対策が考えられる：
1. インスクリプションサイズの制限
インスクリプションサイズを制限することで、ノード負担への影響を軽減できる。冒頭で触れたLuke氏はすでにこれを実施している。
2. インスクリプションの暗号化
インスクリプションを暗号化することで、悪意のあるコード攻撃を防げる。
3. 信頼できるインスクリプション情報源の使用
信頼できるインスクリプション情報源を使用することで、署名問題やフィッシング被害を防げる。
4. インスクリプション対応ウォレットの使用
インスクリプション対応ウォレットを使用して送金を行う。
5. インスクリプションコードおよび関連スクリプトの審査
brc20-swapや再帰的インスクリプションといった新種の実験では、コードおよび関連スクリプトの導入により、これらのコードやスクリプトの安全性を確保する必要がある。
技術的・セキュリティ的観点から言えば、ビットコインインスクリプションは本質的にルール回避の脆弱性であり、Taprootスクリプトはデータ保存のために設計されたものではなく、セキュリティ面にもいくつかの問題がある。Luke氏によるBitcoin Coreコードの修正はセキュリティ観点からは正しい。彼はビットコインのコンセンサス層を直接変更したわけではなく、Spam Filter（ポリシーフィルター）モジュールを調整することで、ノードがP2Pブロードキャストメッセージを受信した際にOrdinals取引を自動的にフィルタリングできるようにしている。このポリシーフィルター内には、isStandard()という複数の関数があり、取引が標準に合致するかどうかを各方面からチェックする。標準に合致しない取引は、ノードが受信しても即座に破棄される。
言い換えれば、Ordinals取引は最終的にブロックチェーンに追加される可能性はあるが、大多数のノードはそのようなデータをトランザクションプールに追加しない。これにより、Ordinalsデータがブロックに取り込まれるのを意図するマイニングプールが受け入れるまでの遅延が増加する。しかし、あるマイニングプールがBRC-20取引を含むブロックをブロードキャストした場合、他のノードは依然としてそれを承認する。
Luke氏はBitcoin Knotsクライアントでポリシーフィルター（policy）の修正をリリースしており、Bitcoin Coreクライアントでも同様の変更を導入する予定である。この修正では、g_script_size_policy_limitという新しいパラメータを導入し、複数の場所でスクリプトサイズを制限している。この変更により、取引処理時にスクリプトサイズが追加制限され、取引の受諾と処理方法に影響を与える。
現在、このパラメータのデフォルト値は1650バイトであり、任意のノードクライアントは起動時に -maxscriptsize パラメータで設定できる：
ただし、コード更新後も、マイナーのノードがすべて新バージョンに更新されるまでには長い時間がかかる。この期間中に、インスクリプションコミュニティのイノベーターたちはより安全なプロトコルを創造できるだろう。
Metatrust Labsはオンチェーンデータと資産追跡を通じ、metaScoreプラットフォームでインスクリプション投資リスクの評価と監視を行っており、またmetaScoutプラットフォームではビットコインネットワーク監視のルールエンジンを提供し、投資家がビットコインインスクリプションのリアルタイムデータを監視できるように支援している。
今号では、注目のインスクリプションエコシステムの技術原理と潜在的なセキュリティ問題を探った。次号では、より複雑なTaproot回路エッチング技術——bitVM——についてご紹介する。どうぞお楽しみに。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
