最近の 2 週間、私は BTC エコシステムとさまざまなインスクリプションプロジェクトを研究している中で、原理や技術的詳細を明確に紹介している記事が非常に少ないことに気付きました。例えば、インスクリプションが鋳造される際に、取引はどのように開始されるのか、UTXO 内の sats はどのように追跡されるのか、インスクリプションの内容はスクリプトのどこに置かれるのか、また BRC20 の送金時に何故 2 回の操作が必要なのか？これらの技術的詳細を理解しないと、BRC20、BRC420、アトミカルズ、スタンプ、ルーンなどのさまざまなプロトコルの違いを理解するのは難しいことがわかりました。本記事では、BTC ブロックチェーンの基礎知識に深く入り込み、上記の質問に答えようと思います。
BTC のブロック構造#
ブロックチェーンは本質的に多ユーザーの記帳技術であり、計算機科学の用語で言えば分散型データベースです。一定の時間内の記録（帳目）が 1 つのブロックを構成し、その後、時間の先後に従って帳簿が拡張されます。
私たちは Excel を使ってブロックチェーンの動作原理を説明する表を作成しました。1 つの Excel ファイルは 1 つのブロックチェーンを表し、各個別の表は 1 つのブロックを示します。ブロックは時間順に 560331、560332、最新の 560336 まで続きます。560336 はブロック内に最近の取引をパッケージ化します。ブロック内部の主体部分は、会計分野で最も一般的な複式簿記法であり、一方のアドレスは借出（debit）として記録され、もう一方のアドレスは貸入（credit）として記録されます。Value は対応するアドレスの BTC の数量に対応します。Inputs のコインの数量は Outputs のコインの数量よりも大きく、差額はユーザー側の送金手数料であり、マイナー（記帳者）が取得する手数料です。ブロックヘッダーは前のブロックの高さ、前のブロックのハッシュ値、本ブロックの構築時間（タイムスタンプ）、およびランダム数を取得します。では、分散型の記帳技術として、次のブロックの記帳権を誰が奪うのでしょうか？それはこのランダム数とそれに対応するハッシュ値によります。計算能力を持つマイナーは、現在のブロックのランダム数をハッシュ計算し、条件を満たすハッシュ値を最初に得たマイナーが次のブロックの記帳権を持ち、ブロック報酬と送金手数料を獲得します。最後にスクリプト領域があり、拡張アプリケーションを行うために使用できます。例えば、スクリプト op_return は附言欄として使用できます。実際のブロックでは、スクリプト領域は input と output 情報に付着しており、実際には別の独立した領域ではありません。例えば、input に付着しているスクリプトはロック解除スクリプト（ScriptSig）であり、ウォレットアドレスによる秘密鍵の署名を必要とし、転出を許可します。一方、output に付着しているスクリプトはロックスクリプト（ScriptPubKey）であり、受け取った BTC のロック解除条件を設定するために使用されます（一般的な条件は「対応する秘密鍵を持つ人のみが消費できる」です）。
上記の 2 つの画像は、元の input と output のデータ構造表です。実行レベルでは、スクリプトは取引情報の付随パラメータとして機能し、ロック解除スクリプト（ScriptSig）は秘密鍵の承認が必要なため、「証人データ」（witness data）とも呼ばれます。
隔離証人と Taproot#
ビットコインネットワークは 10 年以上運用されており、顕著な事件は発生していませんが、取引コストが実行不可能な高値に急上昇することが何度もありました。そのため、ビットコインの開発者たちは、将来の取引量の増加に対処するためにネットワークを最適に拡張する方法について議論してきました。
2017 年、この議論はピークに達し、ビットコイン開発コミュニティは 2 つの派閥に分かれました。一方は、ソフトフォークを使用して SegWit と呼ばれる機能を実装することを支持し、もう一方は直接ブロック拡張を支持する「大ブロック」派です。
前述のように、ロック解除スクリプトは秘密鍵の承認を必要とし、「証人データ」を生成しますが、この証人データをブロックから分離することで、各ブロックが収容できる取引数を増やすことはできるのでしょうか？隔離証人（Segregated Witness）は 2017 年 8 月に正式にアクティブ化されました。その実現方法は、すべての取引データを 2 つの部分に分けることです。一方は取引の基本情報（Transaction Data）、もう一方は取引の署名情報（Witness Data）であり、署名情報は新しいデータ構造に保存され、「隔離証人（witness）」と呼ばれる新しいブロックに保存され、元の取引とは別に送信されます。
技術的には、SegWit の実装は取引がもはや証人データを含む必要がなくなることを意味します（ビットコインが元々ブロックに割り当てた 1MB の空間を占有しません）。その代わりに、ブロックの末尾に証人データのための追加の独立した空間が作成されます。これは任意のデータ転送をサポートし、「ブロック重量（block weight）」という割引があり、大量のデータをビットコインのブロックサイズ制限内に保持する巧妙な方法です。これにより、ビットコイン取引の取引データサイズの上限が引き上げられ、署名データの取引手数料が低下しました。SegWit アップグレード前のビットコインの容量上限は 1MB でしたが、SegWit 以降、単純な取引の容量上限は依然として 1MB ですが、隔離証人空間のサイズは 4MB に達しました。
Taproot は 2021 年 11 月に実装され、3 つの異なるビットコイン改善提案（BIP）から構成されており、Taproot、Tapscript、そして「Schnorr 署名」と呼ばれる新しいデジタル署名スキームが含まれています。Taproot はビットコインユーザーに多くの利点をもたらすことを目的としており、取引のプライバシーを向上させ、取引手数料を削減します。また、ビットコインがより複雑な取引を実行できるようにし、アプリケーションのシナリオを広げます（新しい操作コード opcodes が追加されました）。
これらの更新は Ordinals NFT の重要な推進要因であり、NFT データは Taproot スクリプトパスの支出スクリプト（spent script）内に保存されます（証人データ空間）。このアップグレードにより、任意の証人データの構造化と保存が容易になり、「ord」標準の基礎が築かれました。データ要件が緩和されると、取引がその取引と証人データでブロック全体を満たすことができると仮定すると、4MB のブロックサイズ（証人データ空間）制限に達し、チェーン上に置けるメディアタイプが大幅に拡張されます。
おそらく誰かが尋ねるでしょう、スクリプトにいくつかの文字列を入れると、これらの文字列に制限条件はないのか？もし本当にこれらのスクリプトを実行した場合、内容を自由に入れるとエラーコードが出てブロックが拒否されることはないのか？ここで OP_FALSE 命令について言及する必要があります。OP_FALSE（ビットコインスクリプトでは「0」とも表されます）は、スクリプト言語の実行パスが決して OP_IF 分岐に入らず、未実行の状態を保つことを保証します。これはスクリプト内のプレースホルダーまたは空の操作（No Operation）として機能し、高級言語の「コメント」に似ており、後続のコードが実行されないことを保証します。
UTXO 転送モデル#
上記はコンピュータデータ構造の観点から BTC の基本原理を研究したもので、次に金融モデルの観点から UTXO モデルについて議論します。
UTXO は Unspent Transaction Outputs の略で、中文では「未使用の取引出力」と訳され、実際には 1 回の送金時に残った未転出の資金を理解できます。では、ビットコインはなぜこの概念を使用するのでしょうか？これは記帳方法のアカウント取引モデルとアカウント残高モデルから始まります。
私たちは中央集権的なシステムに長く滞在してきたため、アカウント残高モデルの記帳方法に非常に慣れています。ユーザー A がユーザー B に 100 元を送金する際、銀行はまず A の銀行口座に 100 元があるかどうかを確認し、あれば A の口座から 100 元を引き落とし、B の口座に 100 元を加えます。これで送金が完了します。
しかし、ビットコインの記帳アルゴリズムには残高という概念がありません。ブロックチェーンの分散型台帳には、取引の記録のみが記録され、アカウントの現在の残高は直接記録されません（残高を記録するには、特別なサーバーノードが必要であり、それは中央集権的になります）。仮に現在ユーザー A の残高が 1000 元で、ユーザー A がユーザー B に 100 元を送金すると、この送金は次のように記録されます：
取引 1 ユーザー A がユーザー B に 100 元を送金
取引 2 ユーザー A がユーザー A 自身に 900 元を送金（UTXO）
ここでの取引 2 は 1 つの取引ですが、機能的にはアカウント残高の役割を果たし、100 元の送金を完了した後、A のアカウントには 900 元が残っていることを示します。
では、なぜこのような UTXO を作る必要があるのでしょうか？それは BTC ブロックチェーン上では取引のみが記録され、アカウント残高を記録することができないからです。この UTXO がなければ、残高を計算するにはアカウントのすべての取引の入金と出金をすべて累積する必要があり、非常に時間と計算リソースを消費する作業になります。UTXO の出現は、残高を計算する際にすべての取引を遡るという痛点問題を巧妙に回避しました。
UTXO には特徴があります。それは硬貨のように、分割できないことです。では、取引中にどのように入力金額を集め、どのようにお釣りを出すのでしょうか？硬貨を例に使うことができます（実際には UTXO という単語を見るたびに「硬貨」と自動的に翻訳するのが良いでしょう）。
小明が小刚に 1 ビットコインを送金します。全体のプロセスは次のようになります。小明は十分な input を集める必要があります。例えば、小明のアドレスに対応する過去の取引で、0.9 の UTXO を見つけましたが、1 ビットコインには足りません。幸い、取引では複数の入力が許可されているため、小明は 0.2 の UTXO も見つけました。これにより、この送金取引では 2 つの入力が存在します。同時に出力も 2 つあり、一つは小刚のアドレスを指し、面値は 1 ビットコインです。もう一つは小明自身のアドレスを指し、面値は 0.1 ビットコインで、この出力がお釣りです（この例ではガスは無視します）。
言い換えれば、小明のポケットには 0.9 の硬貨と 0.2 の硬貨が 2 つあり、1 の硬貨を支払う必要がある場合、これら 2 つの硬貨を小刚に渡さなければなりません。小刚は受け取った後、0.1 を小明にお釣りとして返します。したがって、この記帳モデルの本質は「お釣り」の動作を通じて「残高の計算」を回避することです。
Ordinal プロトコルの順序システム#
Ordinal プロトコルは、今回の BTC エコシステムの爆発の源であり、同質の BTC を最小単位の sat に分解し、各 sat に番号を付けるものです。それはどのように行われるのでしょうか？
私たちは、BTC の総量が 2100 万枚であり、1 枚の BTC は最小で 1 億分（sat）に分割できることを知っています。したがって、BTC の最小単位は sat であり、これらの BTC や最小単位の sat は、典型的な同質トークン FT です。私たちはこれらの sats に番号を付けることを試みます（ordinal）。
前述のブロックデータ構造について話すとき、取引情報には input のアドレスと金額、output のアドレスと金額を明記する必要があります。そして、各ブロックには 2 つの部分の取引が含まれています：BTC の出力報酬と送金手数料。手数料取引には必ず input と output がありますが、出力報酬は無から生成された BTC であり、input アドレスがないため、この「input from」フィールドは空白であり、「コインベース取引」と呼ばれます。BTC の総量 2100 万枚はすべてこのコインベース取引から生じており、すべてのブロックの取引リストの最初に配置されています。
Ordinal プロトコルは次のように規定しています：
- 番号付け：各 sat は採掘された順序で番号を付けられます。
- 移転：先入先出ルールに従って、取引の入力から出力に移転します。
最初のルールは比較的簡単で、番号付けはコインベース取引の採掘報酬からのみ生成されることを決定します。例えば、最初のブロックの採掘報酬が 50BTC の場合、最初のブロックは [0;1;2;...;4,999,999,999] の範囲の sats を割り当てます。2 番目のブロックの報酬も 50BTC の場合、2 番目のブロックは [5,000,000,000;5,000,000,001;...;9,999,999,999] の範囲の sats を割り当てます。
ここで理解が難しい部分は、UTXO が実際には多くの sats を含んでいるため、この UTXO 内の各 sats は見た目が同じで、どのように順序を付けるのかということです。これは実際には 2 番目のルールによって決まります。簡単な例を挙げましょう：
私は BTC の最小分割単位が 1 で、合計で 10 のブロックが出ており、各ブロックの出力報酬が 10BTC で、合計は 100BTC であると仮定します。これらの 100BTC には（0-99）の番号を付けることができます。何の支出もない場合、最初のブロックの 10BTC の番号は（0-9）、2 番目のブロックの 10BTC の番号は（10-19）、第十のブロックの 10BTC の番号は（90-99）となります。この中で支出がないため、出力もなく、各 10BTC に番号範囲を付けることしかできません。
仮に 2 番目のブロックに 2 つの支出（output）が追加されるとします。一つは 3BTC、もう一つは「お釣り」の 7BTC で、他の人に 3BTC を送金し、自分に 7BTC のお釣りを返すことに対応します。この時、ブロックの取引リストでは、自分にお釣りの 7BTC が最初にランク付けされ（対応する番号は 10-16）、他の人への 3BTC が 2 番目にランク付けされます（対応する番号は 17-19）。これにより、output の移転を通じて特定の UTXO に含まれる sats の順序集合が確認されました。
注意すべきは、各 sat は UTXO ではないということです！UTXO は分割不可能な最小取引単位であるため、sat は UTXO 内にのみ存在し、UTXO は一定範囲の sats を含み、特定の UTXO を消費した後に新しい出力内で sats の番号付けが行われます。
この「番号付け」を表現する方法については、Ordinal はさまざまな形式をサポートしています。例えば、上記の「整数法」の他に、十進小数法、度数法、百分率法、純文字命名法などがあります。
sats に統一された番号が付けられた後、インスクリプション（inscription）を考慮することができます。前述のように、証人データ領域の 4MB のスペースに任意のデータタイプのファイルをアップロードできます。テキストでも画像でも動画でも、アップロード後、ファイルは自動的に 16 進数に変換され、taproot スクリプト領域に保存されます。したがって、1 つの UTXO は 1 つの Taproot スクリプト領域に対応し、この 1 つの UTXO は同時に多くの sats を含むことになります（全体としては sats のシーケンス集合であり、粉塵攻撃を防ぐために、単一の UTXO 内のビットコインの数量は 546sats 未満にはできません）。Ordinal プロトコルは、記録を容易にするために「このシーケンス集合の最初の sat 番号をバインディング関係を表すために使用する」と規定しています（ホワイトペーパーの原文は「最初の output の最初の sats の番号」）例えば、（17-19）号 sats を含む UTXO は、17 号を直接使用してこの集合とインスクリプション内容をバインドします。
Ordinal 資産の鋳造と転送#
Ordinal NFT は明らかに、さまざまなファイルを隔離証人区のスクリプトにアップロードし、sats のシーケンス集合とバインドすることで、BTC チェーン上で NFT 資産を発行することを実現しています。しかし、ここで 1 つの問題があります。隔離証人区のスクリプトには input のロック解除スクリプトと output のロックスクリプトが含まれているため、内容はどのスクリプトに置かれるのでしょうか？正しい答えは両方にあります。ここで、ブロックチェーン技術のコミット・リビールメカニズムについて言及せざるを得ません。
ブロックチェーンのコミット・リビールメカニズムは、情報の公正かつ透明な処理を確保するためのプロトコルです。このメカニズムは、隠された情報（投票や入札など）を提出し、その後の特定の時点でその情報を明らかにする必要があるシナリオで一般的に使用されます。コミット・リビールメカニズムは 2 つの段階に分かれています：コミット（Commit）段階とリビール（Reveal）段階です。
-
コミット（Commit）段階：この段階では、ユーザーは情報（投票選択や入札価格など）を提出しますが、この情報は暗号化されています。通常、ユーザーはこの情報のハッシュ値（情報の暗号化要約）を生成し、そのハッシュ値をブロックチェーンに送信します。ハッシュ関数の特性により、ユニークな出力（ハッシュ値）が生成され、この出力は元の情報に対して不可逆的です。これは、ハッシュ値から元の情報を推測することができないことを意味します。このプロセスは、提出時の情報の機密性を確保します。
-
リビール（Reveal）段階：あらかじめ定められた後の時点で、ユーザーは元の情報を明らかにし、それが以前に提出されたハッシュ値と一致することを証明する必要があります。これは通常、元の情報とハッシュ値を生成するために使用された追加データ（ランダム数や「塩」など）を提出することによって行われます。ネットワークは、その元の情報のハッシュ値が以前に提出されたハッシュ値と同じであるかどうかを検証します。一致すれば、元の情報は有効として受け入れられます。
前述のように、インスクリプションの内容は UTXO に含まれる sats のシーケンス集合とバインドする必要があります。UTXO はブロック内の output であるため、output のロックスクリプトに付着する必要があります。しかし、BTC の全ノードはローカルで全ネットワークのすべての UTXO 集合を維持し、伝送する必要があります。想像してみてください、1 万個の 4MB の動画ファイルが 1 万個の UTXO のロックスクリプトに直接アップロードされた場合、すべての全ノードは非常に高いストレージスペースと超高速のネットワークが必要になります。言ってしまえば、チェーン全体が崩壊してしまいます。したがって、唯一の解決策は、内容を input のロック解除スクリプトに置き、その内容が別の output を「指す」ようにすることです。
したがって、Ordinal 資産の鋳造は 2 つのステップに分ける必要があります（ウォレットはこれら 2 つのステップを統合して処理します。取引を構築する際に、コミット・リビールという親子取引を同時に構築し、ユーザー体験上は 1 つのステップのように感じられ、ガス代を節約します）。
鋳造段階では、ユーザーはまず特定のファイルのハッシュ値をコミット取引にアップロードする必要があります（自分の A アドレスから自分の B アドレスに送金する）UTXO のロックスクリプトに、ハッシュ値であるため、全ノードの UTXO データベーススペースを過度に占有しません。次に、ユーザーは新しい取引（自分の B アドレスから自分の A アドレスに送金）を構築し、これをリビール取引と呼びます。この時、input は前のステップのコミット取引に含まれるファイルハッシュ値の UTXO を使用する必要があり、その input のロック解除スクリプトには元のインスクリプションファイルが含まれていなければなりません。ホワイトペーパーの原文で表現すると、「まず、コミットでインスクリプション内容を含むスクリプトにコミットする taproot 出力を作成します。次に、リビール取引で、コミット取引から生成された出力を使用して、チェーン上のインスクリプション内容を表示します」となります。
転送段階では、Ordinal NFT は BRC20 とは若干異なります。Ordinal NFT は全体が転送されるため、特定の UTXO にバインドされた NFT を受取人に直接転送するだけで済み、通常の BTC 送金に似ています。しかし、BRC20 はカスタム額の送金に関わるため、同様に 2 つのステップに分かれます。最初のステップはインスクリプション「取引」（Inscribe "TRANSFER"）と呼ばれ、2 番目のステップは転送「取引」（Transfer "TRANSFER"）と呼ばれます。最初のインスクリプション取引は実際には Ordinal NFT の鋳造プロセスに似ており、コミット・リビールの親子取引を暗示しています。2 番目の転送取引は、特定の UTXO にバインドされた BRC20 資産を受取人に直接転送する通常の Ordinal NFT の転送に似ています。一部のウォレットはこれら 3 つの取引（親子孫の 3 世代取引）を同時に構築し、時間とガスを節約します。
要約すると、コミット取引はインスクリプション内容（元の内容のハッシュ値）と番号付けされた sats（UTXO）をバインドするために使用され、リビール取引は内容を表示するために使用されます（元の内容）。この親子取引対は NFT の鋳造を共同で完了します。
P2TR と一例#
上記の鋳造に関する技術的な議論はまだ終わっていません。なぜなら、誰かが好奇心を持つかもしれません。リビール取引はどのようにしてコミット取引のインスクリプション情報を検証するのか？なぜ取引を構築する際に自分の A と B の 2 つのアドレスを相互に転送する必要があるのか？インスクリプションを行う際に 2 つのウォレットを準備する必要はないのではないか？ここで、Taproot の重要なアップグレードの 1 つである P2TR について説明する必要があります。
P2TR（Pay-to-Taproot）は、Taproot アップグレードによって導入された新しいタイプのビットコイン取引です。P2TR 取引は、ユーザーが単一の公開鍵またはより複雑なスクリプト（多重署名ウォレットやスマートコントラクトなど）を使用してビットコインを消費できるようにすることで、より高いプライバシーと柔軟性を実現します。これは、Merkleized Abstract Syntax Trees（MAST）と Schnorr 署名を使用することで実現され、これにより単一の取引内で複数の消費条件を効率的にエンコードできます。
-
消費条件の作成
P2TR 取引を作成するには、ユーザーはまず消費条件を定義します。例えば、単一の公開鍵やより複雑なスクリプトを指定し、ビットコインを消費するための要件を定義します（例えば、多重署名ウォレットやスマートコントラクトなど）。 -
Taproot 出力の生成
次に、ユーザーは Taproot 出力を生成します。この出力には単一の公開鍵（消費条件を表す公開鍵）が含まれます。この公開鍵は、ユーザーの公開鍵とスクリプトのハッシュの組み合わせから派生され、「tweaking」と呼ばれるプロセスを使用します。これにより、出力は標準的な公開鍵のように見え、ブロックチェーン上で他の取引と区別が難しくなります。 -
ビットコインの消費
ユーザーがビットコインを消費したい場合、消費条件が満たされている場合は単一の公開鍵を使用することができ、または元のスクリプトを明らかにし、消費条件を満たすために必要な署名やデータを提供します。これは Tapscript を使用して行われ、消費条件をより効率的かつ柔軟に実行できるようにします。 -
取引の検証
マイナーとノードは、その後、提供された Schnorr 署名とデータを消費条件と照合して取引を検証します。条件が満たされている場合、取引は有効と見なされ、ビットコインが消費されます。 -
プライバシーと柔軟性の向上
P2TR 取引は、ビットコインを消費する際に必要な消費条件のみを明らかにするため、高いレベルのプライバシーを保持します。さらに、MAST と Schnorr 署名を使用することで、複数の消費条件を効率的にエンコードでき、取引の全体的なサイズを増加させることなく、より複雑で柔軟な取引を可能にします。
以上がコミット・リビールメカニズムが P2TR においてどのように適用されるかの説明です。実際のケースを使って説明しましょう。
ブロックチェーンブラウザhttps://www.blockchain.com/を使用して、Ordinal 画像 NFT の鋳造プロセスを研究します。これには、前述のコミット・リビールの 2 つの段階が含まれます。
まず、コミット取引のハッシュ ID は（2ddf90ddf7c929c8038888fc2b7591fb999c3ba3c3c7b49d54d01f8db4af585c）です。この取引の出力にはインスクリプションデータが含まれていないことに注意してください（実際には 16 進数の画像ファイルのハッシュ値が置かれています）。ウェブページには関連するインスクリプション情報はありません。この出力の (bc1p4mtc.....) アドレスは、スクリプトのロック解除条件を表す公開鍵を生成するための「tweaking」プロセスを通じて生成された一時的なアドレスであり、taproot の主アドレス（bc1pg2mp...）と共有される秘密鍵を持っています。この取引の 2 番目の UTXO は返還の「お釣り」操作に属します。こうして、インスクリプション内容と最初の UTXO に含まれる sats のバインディングが実現されました。
次に、リビール取引の記録を確認します。そのハッシュ ID は（e7454db518ca3910d2f17f41c7b215d6cba00f29bd186ae77d4fcd7f0ba7c0e1）です。ここで、Ordinals インスクリプションの情報が表示されます。この取引の input アドレスは、前の取引で生成された一時的出力アドレス（bc1p4mtc.....）であり、input のロック解除スクリプトには元の画像の 16 進数ファイルが含まれています。出力の 0.00000546BTC（546sats）は、この NFT を自分の taproot 主アドレス（bc1pg2mp...）に送信するものです。先入先出の原則に基づき、「バインディングされているのは最初の output の最初の sats の番号」であるため、前後の 2 つの UTXO に含まれる sats の数量は変化しますが、バインディングされた sat の番号は変わりません。したがって、（sat 1893640468329373）でこのインスクリプションが存在する sats を見つけることができます。
（https://ordinals.com/sat/1893640468329373）
これらの取引（親子取引）は、鋳造時にウォレットによって同時にメモリプールに提出されるため、1 回のガス代で済み、非常に高い確率で同じブロックに入ってマイナーによって記録され、ブロードキャストされます（上記の例の 2 つの取引は、ブロック 790468 に同時に存在しています）。マイナーとノードは、その後、リビール取引の input が提供する Schnorr 署名と 16 進数画像のハッシュ値をコミット取引の output ロックスクリプト内の 16 進数画像ハッシュ値と照合して検証します。両者が一致すれば、取引は有効と見なされ、このビットコインの UTXO は消費可能となり、これら 2 つの取引は BTC のブロックチェーンデータベースに永久に記録され、NFT の画像も自然に保存され、表示されます。もし 2 つのハッシュ値が異なれば、2 つの取引はキャンセルされ、インスクリプションは失敗します。
BRC20 プロトコルとインデクサー#
Ordinal プロトコルにおいて、テキストをインスクリプションすればそれは文字 NFT（イーサリアムの Loot に相当し）、画像をインスクリプションすればそれは画像 NFT（イーサリアムの PFP に相当し）、音楽をインスクリプションすればそれは音声 NFT となります。では、コードをインスクリプションし、そのコードが「FT 同質トークン」を発行するコードであればどうなるでしょうか？
BRC20 は、Ordinal プロトコルを利用してインスクリプションを JSON データ形式に設定し、トークンを展開、鋳造、転送するためのものです。JSON にはトークンのさまざまな属性（供給量、最大鋳造単位、ユニークコードなど）を記述するコードスニペットが含まれています。前回の記事で説明したように、BRC20 トークンの本質は半同質トークン SFT であり、つまり、特定の状況では NFT 取引として機能し、他の状況では FT 取引として機能します。この「異なる状況」の制御はどのように行われるのでしょうか？その答えはインデクサーです。
インデクサーは実際には記帳者であり、受け取った情報を分類してデータベースに記録するためのものです。Ordinal プロトコルでは、インデクサーは input と output の追跡を通じて、順序付けされた sats が異なるアドレスでどのように変化するかを特定します。BRC-20 プロトコルでは、インデクサーに新しい機能が追加され、インスクリプション内のトークン残高が異なるアドレスでどのように変化するかを記録します。
したがって、記帳者の視点から異なるトークンの存在形式を見ることができます：BRC20 プロトコルのトークンは実際には 3 重のデータベースに存在します。第一層 Layer1、記帳者は BTC マイナーであり、データベースタイプは「チェーン型データベース」であり、生成される BTC は FT 資産です。第二層 Layer2、記帳者は Ordinal インデクサーであり、データベースタイプは「リレーショナルデータベース」であり、生成される番号付けされた sats は NFT 資産です。第三層 Layer3、記帳者は BRC20 インデクサーであり、データベースタイプは「リレーショナルデータベース」であり、生成される BRC20 資産は FT 資産です。私たちが BRC20 を「張り」として数えるとき、立場は ordinal インデクサー（そのインデクサーが記録したもの）であり、自然に NFT となります。一方、BRC20 を分割された「個」として考えるとき（特に中央集権的な取引所に入金された後）、立場は BRC20 インデクサー（そのインデクサーが記録したものまたは中央集権的な取引所のサーバーが記録したもの）であり、自然に FT となります。これにより、半同質トークン SFT の存在は異なるレベルの記帳者によって引き起こされることがわかります。
ブロックチェーンは分散型データベースであるため、マイナーという記帳者の集団がこの「チェーン型データベース」を共同で維持しています（チェーン型データベースだけが真の分散化を実現できるからです）。しかし、回り道をしても、私たちは依然として中央集権的な「リレーショナルデータベース」の古い道に戻ってしまいます。これが、最近 Ordinal プロトコルの発起人、BRC20 プロトコルの発起人、unisat ウォレットがインデクサーのアップグレードについて激しく議論している本質的な理由でもあります。記帳者の意見が一致しないのです。
しかし、業界は十数年の発展を経て、かなりの「分散化」の経験を蓄積しています。インデクサーは「チェーン型データベース」でリレーショナルデータベースを置き換えることができるのでしょうか？詐欺証明や ZKP を使用して安全性と分散化を保証できるのでしょうか？ビットコインエコシステムの DA 需要は他の DA に溢れ、多チェーンエコシステムの繁栄と融合を促進するのでしょうか？私はより多くの可能性を見出しているように思います。
本文は @hicaptainz によるオリジナルです。
著者をフォローして、web3 で迷わないようにしましょう。
参考資料
https://www.aixinzhijie.com/books/261/master_bitcoin/_book/
https://learnblockchain.cn/article/5717
https://zhuanlan.zhihu.com/p/361854961
https://www.odaily.news/post/5187233
https://learnblockchain.cn/article/5376
https://www.panewslab.com/zh/articledetails/1301r1ibp79c.html