ログイン/ 登録
ETHガス
Gwei
恐怖
UTXOにおけるsatsの追跡方法、铭文（インスクリプション）の内容がスクリプトのどの部分に保存されているのか、そしてBRC20の送金時になぜ2回の操作が必要なのかについて説明します。 ### 1. UTXOにおけるsatsの追跡方法 BitcoinのUTXOモデルでは、各UTXOは特定の量のsatoshis（sats）を持ちます。しかし、ブロックチェーン上では個々のsatsを直接追跡することはできません。代わりに、「所有権」と「移動」はトランザクションの入力と出力を通じて論理的に追跡されます。 - **satsの「追跡」**は実際には「所有権の継承」として実装されています。 - 各トランザクションは、あるUTXOを消費（入力）し、新しいUTXOを生成（出力）します。 - satsは物理的に識別できないため、「最初のsats」「最後のsats」といった概念は存在しません。代わりに、Bitcoin Coreなどのノードソフトウェアは、**satsの順序付けルール**（通称：*consensus order* または *sequential allocation*）を使って、どのsatsがどこに「あるか」を論理的に決定します。 - 具体的には、入力UTXOのsatsは、出力UTXOに**先入れ先出し（FIFO）方式**で割り当てられます。つまり、最初の出力から順にsatsが充填されていきます。 この仕組みにより、特定のsatsがどのUTXOに含まれているかを「論理的に」追跡することが可能になります。これが**satsのトラッキング**の正体です。 --- ### 2. 铭文（インスクリプション）の内容はスクリプトのどこに保存されているか 铭刻（Inscription）とは、Ordinal理論に基づき、特定のsatsにデータ（通常はJSONや画像など）を紐付ける仕組みです。このデータは、**Taprootスクリプト（P2TR）のWitnessフィールド内に埋め込まれます**。 具体的な構造： - Inscriptionは、特別な形式のBitcoinトランザクションとして作成されます。 - データは、`OP_RETURN`ではなく、**Taprootのwitness scriptの中に`OP_PUSHDATA`として挿入**されます。 - そのスクリプトは以下のような形を取ります： ```bitcoin-script <支払先鍵> <署名> <0x00 (OP_FALSE)> <0x6a (OP_RETURN)> <0x50 (サイズ)> <MIMEタイプ> <データ> ``` ただし、正確には、**BIP-340の署名付きTaprootスクリプト**として、以下の流れで実装されます： 1. 新しいP2TRアドレスを作成。 2. Witness内に、`OP_FALSE OP_IF <データ> OP_ENDIF` を含むスクリプトを記述。 3. このスクリプトをコミットし、有効な署名とともにブロードキャスト。 → このデータは、**ネイティブのBitcoinスクリプトとして存在するため、完全にバリデーション対象**となり、ノードがこれを保持する必要があります。 したがって、铭文のデータは： - **場所**：トランザクションのwitnessフィールド内のTapscript - **形式**：`OP_FALSE OP_IF ... OP_ENDIF` ブロック内のバイナリデータ - **アクセス方法**：Ordinal Explorerなどがこのwitnessデータを解析して表示 --- ### 3. BRC20の送金時になぜ2回の操作が必要か BRC20は、Ordinal铭文を利用してトークンを発行・転送するプロトコルですが、**オンチェーンのスマートコントラクト機能がない**ため、すべての状態管理がオフチェーン（インデックスerによる）で行われます。そのため、送金には2段階のトランザクションが必要になります。 #### 手順： 1. **Deploy（デプロイ） or Mint（発行）** - 特定のsatsにJSON形式の銘文を刻む。 - 例：`{"p":"brc-20","op":"deploy","tick":"ordi","max":"21000000","lim":"1000"}` 2. **Transfer（転送）** - 実際の送金は、**2つの独立したトランザクション**で構成される： a. **Transfer Inscription（転送指示の铭文）** - 送信者が自身のUTXOに新しい铭文を刻み、「このBRC20トークンを送る」と宣言。 - 内容例：`{"p":"brc-20","op":"transfer","tick":"ordi","amt":"100"}` - この铭文自体は、**まだトークンの所有権を移していない**。あくまで「送るよ」という意思表示。 b. **Claim（受領／引き出し）** - 受取人が、この「transfer」铭文を検出し、**自分宛の新しい铭文**を刻んで「受け取りました」と宣言。 - 例：`{"p":"brc-20","op":"claim","tick":"ordi","amt":"100"}` - これにより、インデックスerは「所有権が移った」と判断。 #### なぜ2回必要なのか？ - Bitcoinには**ステートフルな契約**（例：ERC-20の`transfer()`関数）がない。 - 銘文は静的データであり、自動実行されない。 - よって、「送る」動作と「受け取る」動作を**両者が自発的に**行う必要がある。 - インデックスer（例：Ord.io, Gamma.io）は、これらの銘文の順序と内容を監視して、最終的な残高を計算。 → 要するに、**プロトコルレベルで強制されず、合意形成ベース**のため、2回の操作が必要になるのです。 --- ### まとめ | 項目 | 説明 | |------|------| | **satsの追跡** | FIFO方式で論理的に割り当て。実際のsatsは同一視できないが、順序ルールで追跡可能 | | **铭文の保存場所** | Taproot witness内のスクリプト（`OP_FALSE OP_IF ... OP_ENDIF`）にバイナリデータとして格納 | | **BRC20の2回操作** | 「transfer」で送信宣言、「claim」で受領宣言。Bitcoinの状態管理能力の欠如により、インデックスer依存のオフチェーン処理が必要 | このように、BRC20やOrdinalはBitcoinの最小限のスクリプト機能を巧みに拡張したものですが、その代償としてUXの複雑さや手数の増加があります。
Substack 今すぐ購読