NFTDriveの記録形式

このページは、BEYOND 0.9.0-beta.1 を対象とする2026年10月13日付の技術資料に基づき、NFTDriveのファイル記録形式を整理したものです。将来の版や任意のカスタムネットワークに、同じ構成値が適用されるとは限りません。暗号化封筒の完全な仕様や、デコーダー実装の全要件を定義するものではありません。

全体の流れは NFTDriveの保存メカニズムを参照してください。

アドレスの役割

アドレス	役割
記録者アドレス	記録一覧を取得する入口。データアドレスへの参照をたどる
作業用アドレス	記録処理用に生成し、データ送信の署名や手数料支払いなどに使用する
データアドレス	1レコードを構成するデータ用Transferの宛先
作者アドレス	ヘッダー内の宣言情報。トランザクション署名者と同一とは限らない

記録一覧用の関連付けとファイル本体は別です。データの取得時には、対象ネットワークとデータアドレスを併せて指定します。

保存形式

形式	分割前のデータ
Base64・平文	`data:<MIME>;base64,...` 形式の文字列
バイナリ・平文	元ファイルのバイト列
Base64・暗号化	`BYNDE1.` で始まる暗号化封筒文字列
バイナリ・暗号化	`BYNDB1` のバイナリ封筒

暗号化封筒は、暗号文と復号に必要な関連情報をまとめる形式です。Base64・暗号化ではdataURLを暗号化し、封筒本体もBase64化します。バイナリ・暗号化では元のバイト列を暗号化し、暗号文をBase64化せず格納します。

Base64では本体部分が元のバイト列のおおむね4/3になります。バイナリはこの増加を避けられますが、ヘッダーやトランザクション構造などの記録量は別に必要です。本体部分の削減率が、そのまま総記録量や手数料の削減率になるわけではありません。実際の上限は記録サイズの制約を参照してください。

データ片とAggregateの構成

ここでは、ファイルから切り出したデータ片を「チャンク」、Aggregate内の内部Transferの位置を「スロット」と呼びます。スロットは0から数えます。

NFTDriveの形式では、ファイルを構成するAggregateに順序番号を付けます。この番号は資料や実装で「ブロック番号」と呼ばれますが、チェーンのブロック高とは別です。以下では「Aggregate番号」と表記します。1ファイルが複数のチェーンブロックにまたがることもあります。

対象版では、1チャンクは最大1023バイト、1つのAggregateは最大100スロットで構成します。これは実装の構成値であり、対象ネットワークの受け入れ条件を確認する必要があります。

先頭のAggregate（番号0）

スロット	内容
0	Aggregate番号 `0`
1	宣言された作者アドレス
2	モザイクIDまたは識別子
3	シリアル番号
4	メッセージ
5〜14	10個の拡張フィールド
15	Base64では本体の最初のチャンク。バイナリでは独立した形式ヘッダー
16〜99	本体チャンクの続き

バイナリの形式ヘッダーは、平文では nftdrive;binary/<MIME>、暗号化では nftdrive;binary/encrypted;<MIME> です。

先頭Aggregateに入る本体チャンクはBase64で最大85個、バイナリで最大84個です。Base64のスロット15を独立したヘッダーとして除外すると、本体の先頭が欠落します。

2つ目以降のAggregate

スロット	内容
0	Aggregate番号 `1`、`2`、…
1〜99	本体チャンク。最大99個

データ用Transferのメッセージは 0x00 + データ片 です。先頭の1バイトを含むメッセージは最大1024バイトになります。データ用Transferのモザイク配列は空であり、チャンクとともに通貨を転送する必要はありません。書き込み時の手数料は、対象ネットワークの条件に従います。

計算例：1MiBの平文バイナリ

元ファイル：1,048,576バイト
チャンク数：ceil(1,048,576 / 1023) = 1,026

Aggregate 0     ：84チャンク
Aggregate 1〜9  ：99 × 9 = 891チャンク
Aggregate 10    ：51チャンク
合計           ：1,026チャンク / 11 Aggregate

これは本体格納用Aggregateの数です。入金、アカウント制限、NFT発行、返金などの処理は含みません。

読み戻し時の扱い

対象ネットワークから、データアドレスに関連するブロック取り込み済みのトランザクションを取得する。
各Aggregateのスロット0を読み、Aggregate番号順に並べる。APIの返却順やチェーンのブロック高順をファイル内の順序として使わない。
先頭Aggregateのスロット15から保存形式を判別する。
Aggregate番号とスロット順に本体チャンクを連結する。バイナリはUTF-8文字列へ変換せず、バイト列として扱う。
暗号化されていれば対応する鍵や共有パスワードで復号し、保存形式に応じてファイルを復元する。
チャンクの欠落や復元失敗を確認し、取得元、対象ネットワーク、トランザクションとブロックの関係を検証する。

REST APIのメッセージはHEX表現です。例えば 0068656c6c6f は、先頭の 00 を除くと hello のバイト列になります。バイナリデータではテキスト変換を挟まず、HEXからバイト列へ戻す必要があります。

記録・検証の範囲

本体格納にはAggregate Completeを使います。ファイルが複数のAggregateに分かれる場合、ファイル全体を一度に確定・取り消す処理ではありません。一部だけが取り込まれた記録も残り得ます。
APIの送信受付、ブロックへの取り込み、ネットワーク上のファイナライズは別の段階です。
通常のアカウントロックは、データアドレスへの受信元を作業用アドレスに制限する処理です。暗号化や過去の記録の削除ではありません。公開鍵秘匿モードではこの処理を省略します。
ファイル本体の暗号化は、公開ヘッダーや署名者・宛先の秘匿を意味しません。暗号化バイナリのMIMEも形式ヘッダーに残ります。
Verified Driveの expectedHash は初回取得バイト列から計算するローカル基準です。独立したオンチェーンのコンテンツハッシュとの一致証明とは異なります。詳細は Verified Drive を参照してください。

暗号化の操作と鍵の保全はファイルを暗号化する、書き込み途中の状態と再開はデータを書き込むにまとめています。

アドレスの役割​

保存形式​

データ片とAggregateの構成​

先頭のAggregate（番号0）​

2つ目以降のAggregate​

計算例：1MiBの平文バイナリ​

読み戻し時の扱い​

記録・検証の範囲​