最近の 2 週間、私は BTC エコシステムとさまざまなインスクリプションプロジェクトを研究している中で、原理や技術的詳細を明確に紹介している記事が非常に少ないことに気付きました。例えば、インスクリプションが鋳造される際に、取引はどのように開始されるのか、UTXO 内の sats はどのように追跡されるのか、インスクリプションの内容はスクリプトのどこに置かれるのか、BRC20 の送金時に何故 2 回の操作が必要なのかなどです。これらの技術的詳細を理解しないと、BRC20、BRC420、atomicals、stamps、ルーン Runes などのさまざまなプロトコルの違いを理解するのは難しいと感じました。本記事では、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 元を加算します。これで 1 回の送金が完了します。
しかし、ビットコインの記帳アルゴリズムには残高という概念がありません。ブロックチェーンの分散型台帳には、取引の記録のみが記録され、アカウントの現在の残高は直接記録されません（残高を記録するには専用のサーバーノードが必要であり、それは中心化になります）。仮に現在ユーザー A の残高が 1000 元で、ユーザー A がユーザー B に 100 元を送金すると、この送金は次のように記録されます：
取引 1 ユーザー A がユーザー B に 100 元を送金
取引 2 ユーザー 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」のフィールドは空白であり、「coinbase 取引」とも呼ばれます。BTC の総量 2100 万枚はすべてこの coinbase 取引から来ており、すべてのブロックの取引リストの最初に配置されています。
Ordinal プロトコルは次のように規定しています：
- 番号付け：各 sat は採掘された順序で番号付けされます
- 移転：先入先出ルールに従い、取引の入力から出力に移転します
最初のルールは比較的簡単で、番号付けは採掘報酬の coinbase 取引からのみ生成されることを決定します。例えば、最初のブロックの採掘報酬が 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）となります。この中で支出がないため、output もないので、10BTC ごとに番号範囲を付けることしかできません。
仮に 2 番目のブロックに 2 つの支出（output）が追加された場合、1 つは 3BTC、もう 1 つは「お釣り」の 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 のロックスクリプトの両方を含んでいますが、内容はどちらのスクリプトに置かれるのでしょうか？正しい答えは両方です。ここでブロックチェーン技術におけるコミット・リビール（commit-reveal）メカニズムについて触れざるを得ません。
ブロックチェーンのコミット・リビールメカニズムは、情報を公正かつ透明に処理するためのプロトコルです。このメカニズムは、隠された情報（投票や入札など）を提出し、その後の特定の時点でその情報を明らかにする必要があるシナリオで一般的に使用されます。コミット・リビールメカニズムは 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）
これら 2 つの取引（親子取引）は、鋳造時にウォレットによって同時にメモリプールに提出されるため、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