NFTokenPage
NFTokenPage
オブジェクトは、同じアカウントが所有するNFTのコレクションを表します。一つのアカウントは複数のNFTokenPage
エントリを持つことができ、それらは双方向リストを形成します。
(NonFungibleTokensV1_1 amendmentにより追加されました)
NFTokenPageのJSONの例
{ "LedgerEntryType": "NFTokenPage", "PreviousPageMin": "8A244DD75DAF4AC1EEF7D99253A7B83D2297818B2297818B70E264D2000002F2", "NextPageMin": "8A244DD75DAF4AC1EEF7D99253A7B83D2297818B2297818BE223B0AE0000010B", "PreviousTxnID": "95C8761B22894E328646F7A70035E9DFBECC90EDD83E43B7B973F626D21A0822", "PreviousTxnLgrSeq": 42891441, "NFTokens": [ { "NFToken": { "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65", "URI": "697066733A2F2F62616679626569676479727A74357366703775646D37687537367568377932366E6634646675796C71616266336F636C67747179353566627A6469" } }, /* 更に多くのオブジェクト */ ] }
NFTokenPageのフィールド
共通フィールドに加えて、NFTokenPageエントリは以下のフィールドを使用します。
名前 | JSONの型 | 内部の型 | 必須? | 説明 |
---|---|---|---|---|
LedgerEntryType | 文字列 | UInt16 | はい | レジャーオブジェクトのタイプを識別文字列です。予約されているレジャーの種類は、0x0050です。 |
NextPageMin | 文字列 | Hash256 | いいえ | 次のページの位置情報(もしあれば)。このフィールドの使用方法は、NFTokenオブジェクトの追加の項に記載しています。 |
NFTokens | オブジェクト | TOKEN | はい | このNFTokenPageオブジェクトに含まれるNFToken オブジェクトのコレクション。本仕様では、1ページあたり32のNFTokenオブジェクトを上限としています。オブジェクトは、NFTokenID をソートパラメータとして使用して、低いものから高いものへとソートされた順序で格納されています。 |
PreviousPageMin | 文字列 | Hash256 | いいえ | 前のページの位置情報(もしあれば)。このフィールドの使用方法は、NFTokenオブジェクトの追加の項に記載しています。 |
PreviousTxnID | 文字列 | HASH256 | いいえ | このNFTokenPageオブジェクトを最も最近変更したトランザクションのトランザクションIDの情報を示します。 |
PreviousTxnLgrSeq | 数値 | UInt32 | いいえ | このNFTokenPageオブジェクトを最も最近変更したトランザクションを含むレジャーのシーケンスを示します。 |
NFTokenPage IDのフォーマット
NFTokenPage
識別子は、NFTokens
に最適で、より効率的なページング構造を採用できるように特別に構築されています。
NFTokenPage
の識別子は、そのページの所有者の160ビットのAccountID
と、そのページに特定のNFTokenID
が含まれるかどうかを示す96ビットの値を連結して得られます。
具体的には、関数low96(x)
が256ビットの値の下位96ビットを返すと仮定すると、NFTokenID
A
のNFTはNFTokenPageID
B
のページに含めることができるのはlow96(A) >= low96(B)
の場合のみとなります。
例えば、000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65
というIDを持つ先ほどのNFTにlow96
関数を適用すると、42540EE208C3098E00000D65
が返されます。
この不思議な構造は、SHAMapの構造を利用して、NFTokenPages
の二重リンクされたリストを反復することなく、個々のNFToken
オブジェクトを効率的に検索できるようにするものです。
NFToken
オブジェクトの検索
特定のNFToken
を検索するには、上記のように所有者のアカウントとトークンのNFTokenID
を使用してNFTokenPageID
を計算します。識別子がその値以下であるレジャーの項目を検索します。そのエントリが存在しないか、NFTokenPage
でない場合、NFToken
は与えられたアカウントによって保持されていません。
NFToken
オブジェクトの追加
NFToken
オブジェクトを追加するには、そのオブジェクトが含まれるべきNFTokenPage
を見つけ(NFToken
オブジェクトを検索するのと同じテクニックを使用します)、そのページに追加します。NFTokenPage
が一杯である場合、前後のページを検索し、その3ページでバランスをとりながら、必要に応じて新しいNFTokenPage
を挿入します。
NFToken
オブジェクトの削除
NFToken
の削除も追加と同じように動作します。ページ内のNFToken
の数がある閾値を下回ると、サーバはそのページを前後のページと統合して準備金を取り戻そうとします。
NFTokenPageの準備金
NFTokenPage
ごとに、所有者アカウントに追加で準備金の費用がかかります。つまり、複数のNFTを保有するアカウントでは、NFTあたりの 実効 準備金コストは R /32( R は準備金増分)と低くすることが可能です。
準備金の実例
ページの分割と結合が機能するため、1ページあたりのNFToken
オブジェクトの実際の数はやや予測不可能で、関係する実際のNFTokenID
値に依存します。実際には、大量のNFTをミントまたは受領した後、各ページには16個のアイテムしかないこともあれば、32個のアイテムしかないこともあります。
以下の表は、様々なシナリオの下で、様々な数のNFTを所有した場合の所有準備金の合計を示したものです。
所有NFTの数 | 最良のケース | 一般 | 最悪のケース |
---|---|---|---|
32以下 | 0.2 XRP | 0.2 XRP | 0.2 XRP |
50 | 0.4 XRP | 0.6 XRP | 0.8 XRP |
200 | 1.4 XRP | 1.8 XRP | 2.6 XRP |
1000 | 6.4 XRP | 8.4 XRP | 12.6 XRP |
これらの数字は推定であり、実際の数字とは異なる場合があります。