FAQ

Summary

このページはBubblegum V2の圧縮NFTに関する最も一般的な質問に答えています。

• getAssetWithProofを使用してリーフを変更する命令の必須パラメータを取得する
• truncateCanopyまたはアドレスルックアップテーブルで「トランザクションが大きすぎる」エラーを解決する
• ツリーを作成する前にツリーのコストと容量を理解する
• Bubblegum V2はV1ツリーや圧縮解除との後方互換性はない
• cNFTはMPL-CoreコレクションのRoyaltiesプラグインからセラーフィーベーシスポイントを継承できる

Bubblegum V2とは何ですか？

Bubblegum V2は、いくつかの改良と新機能を導入するBubblegumプログラムの新しい反復です。 これは既知のBubblegumプログラムの一部ですが、命令とデータ構造は異なります。 Bubblegum V2では、cNFTはMetaplex Token Metadataコレクションの代わりにMPL-Coreコレクションを使用してコレクションにグループ化されます。また、凍結、解凍、ソウルバウンドNFTなどの新機能と以下のような追加機能も導入しています：

• 凍結・解凍機能: プロジェクト作成者は、特定のイベント中の転送を防ぐことや権利確定メカニズムの実装など、さまざまなユースケースでアセットをより詳細に制御するためにcNFTを凍結・解凍できるようになりました。
• MPL-Coreコレクション統合: Bubblegum V2 NFTは、トークンメタデータコレクションに限定されることなく、MPL-Coreコレクションに追加できるようになり、より大きなMetaplexエコシステムとの柔軟性と統合を可能にします。
• ロイヤリティ強制: Bubblegum V2はMPL-Coreコレクションを使用しているため、ProgramDenyListなどを使用してcNFTにロイヤリティを強制することが可能です。
• ソウルバウンドNFT: cNFTをソウルバウンド（転送不可）にすることが可能になり、所有者のウォレットに永続的に紐づけられます。これは資格、出席証明、身元確認などに最適です。コレクションでPermanentFreezeDelegateプラグインを有効にする必要があります。
• 永続転送の許可: コレクションでPermanentTransferDelegateプラグインが有効になっている場合、永続転送デリゲートはリーフ所有者の相互作用なしにcNFTを新しい所有者に転送できます。

転送、デリゲート、バーンなどの操作に必要な引数はどのように見つけますか？

転送、デリゲート、バーンなどのBubblegumツリー内のリーフを置き換える命令を使用するたびに、プログラムは現在のリーフが有効で更新できることを確認するために使用される多くのパラメータを必要とします。これは、圧縮NFTのデータがオンチェーンアカウント内で利用できないため、プログラムがピースを埋めるために証明、リーフインデックス、ノンスなどの追加パラメータが必要だからです。

すべての情報は、getAssetとgetAssetProofの両方のRPCメソッドを使用してMetaplex DAS APIから取得できます。ただし、これらのメソッドからのRPCレスポンスと命令で期待されるパラメータは全く同じではなく、一方から他方への解析は簡単ではありません。

幸いなことに、私たちのSDKは、以下のコード例で見ることができるように、すべての重い作業を行うヘルパーメソッドを提供します。圧縮NFTのアセットIDを受け入れ、バーン、転送、更新などのリーフを置き換える命令に直接注入できる多くのパラメータを返します。

とはいえ、その解析を自分で行う必要がある場合のために、命令で期待されるパラメータとMetaplex DAS APIからそれらを取得する方法の簡単な内訳を以下に示します。ここでは、getAssetとgetAssetProof RPCメソッドの結果が、それぞれrpcAssetとrpcAssetProof変数を介してアクセス可能であると仮定します。

• リーフ所有者: rpcAsset.ownership.ownerを介してアクセス可能。
• リーフデリゲート: rpcAsset.ownership.delegateを介してアクセス可能で、nullの場合はrpcAsset.ownership.ownerにデフォルト設定する必要があります。
• マークルツリー: rpcAsset.compression.treeまたはrpcAssetProof.tree_idを介してアクセス可能。
• ルート: rpcAssetProof.rootを介してアクセス可能。
• データハッシュ: rpcAsset.compression.data_hashを介してアクセス可能。
• 作成者ハッシュ: rpcAsset.compression.creator_hashを介してアクセス可能。
• ノンス: rpcAsset.compression.leaf_idを介してアクセス可能。
• インデックス: rpcAssetProof.node_index - 2^max_depthを介してアクセス可能。ここでmax_depthはツリーの最大深度で、rpcAssetProof.proof配列の長さから推測できます。
• 証明: rpcAssetProof.proofを介してアクセス可能。
• メタデータ: 現在、rpcAssetレスポンス内のさまざまなフィールドから再構築する必要があります。

import { getAssetWithProof, transferV2 } from '@metaplex-foundation/mpl-bubblegum'

const assetWithProof = await getAssetWithProof(umi, assetId, 
// {  truncateCanopy: true } // 証明を剪定するためのオプション 
);
await transferV2(umi, {
  ...assetWithProof,
  leafOwner: leafOwnerA, // 署名者として。
  newLeafOwner: leafOwnerB.publicKey,
}).sendAndConfirm(umi);

「トランザクションが大きすぎる」エラーを解決する方法

転送やバーンなどのリーフ置換操作を行う際、「トランザクションが大きすぎる」エラーが発生することがあります。解決するには次の方法を検討してください：

1. truncateCanopy オプションを使用する： getAssetWithProof 関数に { truncateCanopy: true } を渡します：

   const assetWithProof = await getAssetWithProof(umi, assetId, 
    { truncateCanopy: true }
   );
   

   このオプションはマークルツリー設定を取得し、キャノピーに基づいて不要な証明を削除して assetWithProof を最適化します。追加のRPC呼び出しが発生しますが、トランザクションサイズを大幅に削減します。

2. バージョン管理トランザクションとアドレスルックアップテーブルを使用する： 別のアプローチとして、バージョン管理トランザクションとアドレスルックアップテーブルを実装できます。

これらの手法を適用することで、トランザクションサイズ制限を克服し、操作を正常に実行できます。

1つのツリーにcNFTをいくつ保存できますか？

cNFTの最大数は 2^maxDepth です。深度14のツリーは16,384個、深度20は約100万個、深度24は約1,600万個、深度30は10億を超えるcNFTを保持できます。すべてのオプションについてはツリー容量表を参照してください。

cNFTはMPL-Coreコレクションからロイヤリティを継承できますか？

はい。Royalties プラグインを持つMPL-Coreコレクションにミントする場合、metadata.sellerFeeBasisPoints を省略（または SELLER_FEE_BASIS_POINTS_INHERIT、65535 を渡す）できます。リーフにはそのセンチネルがオンチェーンに保存されます。DASは表示用に royalty.basis_points / creators にコレクションから解決された料率を置き、royalty.basis_points_raw / creators_raw にリーフセンチネルを置きます（royalty.inherited: true）。

要件:

• コレクションには BubblegumV2 と Royalties の両方のプラグインが必要です。
• 継承されたセラーフィーを使用する場合、metadata.creators は空の配列である必要があります。

getAssetWithProof の使用:

• metadata — DAS の主/表示フィールドをミラー（継承時の sellerFeeBasisPoints はコレクション解決料率）。
• currentMetadata — 書き込み用のリーフ正規 MetadataArgsV2Args（継承時はセンチネル）。
• sellerFeeBasisPointsRaw / creatorsRaw — 任意のリーフ兄弟；継承 / DAS が _raw を返すときのみ。
• inherited — 継承検出のシュガー。
• rpcAsset — 完全な DAS レスポンス（表示は royalty.basis_points / creators）。

updateMetadataV2 では ...assetWithProof を展開して currentMetadata を渡します。リーフ metadata 引数を取る命令では assetWithProof.currentMetadata を使います。

コレクション管理:

• 継承されたセラーフィーを持つcNFTは、明示的な sellerFeeBasisPoints に更新するまでコレクションから削除できません。
• 移行先に Royalties プラグインがある場合、別のコレクションへの移動は許可されます。

DASを読むクライアントは継承ロイヤリティの読み取りを参照し、詳細な例についてはミント — ロイヤリティの継承、cNFTの更新、コレクションの管理を参照してください。