Core Candy Machineからのミント

概要

mintV1命令は、ロードされたCore Candy Machineからアクセス制御のためにCandy Guardプログラムを経由し、実際のミントをCore Candy Machineプログラムに委譲してCore Assetを作成します。

• 2つのミントパス: Candy Guardプログラム経由のミント（推奨、ガードサポート）またはCore Candy Machineプログラムからの直接ミント（ミント権限の署名が必要）
• Mint Settings: ランタイムデータを必要とするガード（Third Party SignerやNFT Paymentなど）は、ミント時に追加のmintArgsが必要
• ガードグループ: ガードグループが設定されている場合、ミントするグループラベルを指定する必要があり、Mint Settingsはそのグループの解決されたガードに適用
• 事前検証: 一部のガード（Allow ListやGatekeeperなど）はmint命令が成功する前に別の検証ステップが必要

基本的なミント

Core Candy Machineはミントを処理するために2つのオンチェーンプログラムを使用します：Core Candy Machineプログラム（実際のミントロジックを担当）とCandy Guardプログラム（その上に設定可能なアクセス制御レイヤーを追加）。Candy Guardsページで説明されているように、これらのプログラムは柔軟なミントワークフローを可能にするために連携して機能します。

Core Candy Machineからミントする方法は2つあります：

• Candy Guardプログラムからのミント。Candy Machine Coreプログラムにミントを委譲します。はるかに複雑なミントワークフローを可能にするため、ほとんどの場合これを行いたいでしょう。アカウントで設定されたガードに基づいて、ミント命令に追加の残存アカウントと命令データを渡す必要があるかもしれません。幸いなことに、SDKはいくつかの追加パラメータを要求し、残りを計算してくれるため、これを簡単にします。

• Core Candy Machine Coreプログラムからの直接ミント。この場合、設定されたミント権限のみがミントでき、したがってトランザクションに署名する必要があります。

すべてが順調に進んだ場合、Core Candy Machineで設定されたパラメータに従ってNFTが作成されます。例えば、指定されたCore Candy MachineがConfig Line Settingsを使用し、Is Sequentialがfalseに設定されている場合、次のアイテムをランダムに取得します。

import { mintV1 } from "@metaplex-foundation/mpl-core-candy-machine";
import { setComputeUnitLimit } from "@metaplex-foundation/mpl-toolbox";
import { generateSigner } from "@metaplex-foundation/umi";

const candyMachineId = publicKey("11111111111111111111111111111111");
const coreCollection = publicKey("22222222222222222222222222222222");
const asset = generateSigner(umi);

await mintV1(umi, {
  candyMachine: candyMachineId,
  asset,
  collection: coreCollection,
}).sendAndConfirm(umi);

import { mintFromCandyMachineV2 } from '@metaplex-foundation/mpl-core-candy-machine'
import { setComputeUnitLimit } from '@metaplex-foundation/mpl-toolbox'
import { transactionBuilder, generateSigner } from '@metaplex-foundation/umi'

const candyMachineId = publicKey('11111111111111111111111111111111')
const coreCollection = publicKey('22222222222222222222222222222222')
const asset = generateSigner(umi)

await mintAssetFromCandyMachine(umi, {
  candyMachine: candyMachineId,
  mintAuthority: umi.identity,
  assetOwner: umi.identity.publicKey,
  asset,
  collection: coreCollection,
}).sendAndConfirm(umi);

ガード付きミント

ランタイム情報を必要とするガードはMint Settingsを使用します。署名者参照、トークンミントアドレス、制限識別子などのガード固有データをmintArgs経由で渡す追加パラメータです。ミント命令を手動で構築する場合、その情報は命令データと残存アカウントの混合として提供されます。しかし、SDKを使用すると、ミント時に追加情報を必要とする各ガードは、Mint Settingsと呼ぶ設定セットを定義します。これらのMint Settingsは、プログラムが必要とするものに解析されます。

Mint Settingsを必要とするガードの良い例はNFT Paymentガードで、これはミントの支払いに使用すべきNFTのミントアドレスなどを必要とします。

利用可能な各ガードには独自のドキュメントページがあり、そのガードがミント時にMint Settingsの提供を期待するかどうかを教えてくれます。

Mint Settingsを必要としないガードのみを使用する場合、上記の「基本的なミント」セクションで説明したのと同じ方法でミントできます。そうでなければ、それらを必要とするすべてのガードのMint Settingsを含む追加のオブジェクト属性を提供する必要があります。SDKを使用して実際にどのように見えるかを見てみましょう。

import {
  some,
  generateSigner,
  transactionBuilder,
} from '@metaplex-foundation/umi'
import { create, mintV1 } from '@metaplex-foundation/mpl-core-candy-machine'
import { setComputeUnitLimit } from '@metaplex-foundation/mpl-toolbox'

// ガード付きCore Candy Machineを作成します。
const thirdPartySigner = generateSigner()
await create(umi, {
  // ...
  guards: {
    thirdPartySigner: some({ signer: thirdPartySigner.publicKey }),
    mintLimit: some({ id: 1, limit: 3 }),
  },
}).sendAndConfirm(umi)

// Core Candy Machineからミントします。
const nftMint = generateSigner(umi)
await transactionBuilder()
  .add(setComputeUnitLimit(umi, { units: 300_000 }))
  .add(
    mintV1(umi, {
      candyMachine: candyMachineId,
      asset,
      collection: coreCollection,
      mintArgs: {
        thirdPartySigner: some({ signer: thirdPartySigner }),
        mintLimit: some({ id: 1 }),
      },
    })
  )
  .sendAndConfirm(umi)

ガードグループでのミント

ガードグループが設定されている場合、mint命令にはミントするグループを選択するための明示的なgroupラベルが必要です。Mint Settingsは選択されたグループの解決されたガード -- そのグループのガードとデフォルトガードのマージされた組み合わせ -- に適用されます。

例えば、以下のガードを持つCore Candy Machineを想像してください：

• デフォルトガード:
  • Bot Tax
  • Third Party Signer
  • Start Date
• グループ1
  • ラベル: "nft"
  • ガード:
    • NFT Payment
    • Start Date
• グループ2
  • ラベル: "public"
  • ガード:
    • Sol Payment

グループ1（"nft"ラベル）の解決されたガードは：

• Bot Tax: デフォルトガードから。
• Third Party Signer: デフォルトガードから。
• NFT Payment: グループ1から。
• Start Date: デフォルトガードを上書きするためグループ1から。

したがって、提供されるMint Settingsはこれらの解決されたガードに関連する必要があります。上記の例では、Third Party SignerガードとNFT PaymentガードにMint Settingsを提供する必要があります。

// ガード付きCore Candy Machineを作成します。
const thirdPartySigner = generateSigner()
await create(umi, {
  // ...
  guards: {
    botTax: some({ lamports: sol(0.001), lastInstruction: true }),
    thirdPartySigner: some({ signer: thirdPartySigner.publicKey }),
    startDate: some({ date: dateTime('2022-10-18T17:00:00Z') }),
  },
  groups: [
    {
      label: 'nft',
      guards: {
        nftPayment: some({ requiredCollection, destination: nftTreasury }),
        startDate: some({ date: dateTime('2022-10-18T16:00:00Z') }),
      },
    },
    {
      label: 'public',
      guards: {
        solPayment: some({ lamports: sol(1), destination: solTreasury }),
      },
    },
  ],
}).sendAndConfirm(umi)

// Core Candy Machineからミントします。

const candyMachineId = publicKey('11111111111111111111111111111111')
const coreCollection = publicKey('22222222222222222222222222222222')
const asset = generateSigner(umi)

await transactionBuilder()
  .add(setComputeUnitLimit(umi, { units: 300_000 }))
  .add(
    mintV1(umi, {
      candyMachine: candyMachineId,
      asset,
      collection: coreCollection,
      group: some('nft'),
      mintArgs: {
        thirdPartySigner: some({ signer: thirdPartySigner }),
        nftPayment: some({
          mint: nftFromRequiredCollection.publicKey,
          destination: nftTreasury,
          tokenStandard: TokenStandard.NonFungible,
        }),
      },
    })
  )
  .sendAndConfirm(umi)

事前検証付きミント

一部のガードは、mint命令が成功する前に追加の検証ステップを必要とします。この事前検証ステップは通常、オンチェーンアカウントを作成するか、適格性の証明として機能するトークンを発行し、mint命令が実行時にチェックします。

Route命令による事前検証

route命令は、ガードがミント前の検証のために独自のカスタム命令を実行できるようにします。ガードがroute命令の内容を定義し、結果のオンチェーン証明が後続のmint呼び出し中にチェックされます。

その良い例はAllow Listガードです。このガードを使用する場合、route命令を呼び出し、有効なMerkle Proofを提供することで、ウォレットが事前定義されたウォレットリストに属することを確認する必要があります。このroute命令が成功すると、そのウォレット用のAllow List PDAが作成され、mint命令がAllow Listガードを検証するために読み取ることができます。Allow Listガードについて専用ページで詳しく読むことができます。

外部サービスによる事前検証

一部のガードは、route命令を使用する代わりに、外部サービスに事前検証を委譲します。外部サービスがトークンまたは資格情報を発行し、ガードがミント時にそれをチェックします。

例えば、Gatekeeperガードを使用する場合、設定されたGatekeeper Networkに応じてチャレンジ（Captchaの完了など）を実行することでGateway Tokenをリクエストする必要があります。Gatekeeperガードは、ミントを検証または拒否するために、そのようなGateway Tokenの存在をチェックします。Gatekeeperガードについて専用ページで詳しく学ぶことができます。

ボット税付きミント

Bot Taxガードは、トランザクションを元に戻すのではなく、失敗したミントに設定可能なSOL手数料を課金することで、Core Candy Machineをボットから保護します。この金額は通常、実際のユーザーの本物の間違いに影響を与えることなくボットを傷つけるために小さく設定されます。すべてのボット税はCore Candy Machineアカウントに転送されるため、ミント完了後にCore Candy Machineアカウントを削除してこれらの資金にアクセスできます。

このガードは少し特別で、他のすべてのガードのミント動作に影響を与えます。Bot Taxが有効化され、他のガードのミント検証が失敗した場合、トランザクションは成功したふりをします。これは、プログラムからエラーが返されませんが、NFTもミントされないことを意味します。これは、ボットからCore Candy Machineアカウントに資金を転送するためにトランザクションが成功する必要があるためです。Bot Taxガードについて専用ページで詳しく学ぶことができます。

注意事項

• コンピュートユニット制限: 複数のガードを使用したミントはデフォルトのコンピュートバジェットを超える可能性があります。@metaplex-foundation/mpl-toolboxのsetComputeUnitLimitを使用して制限を増やしてください。300_000ユニットが一般的な出発点ですが、アクティブなガードの数に基づいて調整してください。
• minterとpayer署名者: Candy Guardプログラムv1.0から、mintV1命令は別々のminterとpayer署名者を受け取ります。payerはSOL手数料（レント、SOL支払いガード）をカバーし、minterはガードに対して検証され、トークンベースの手数料をカバーします。明示的に設定されない場合、両方ともUmiのidentityとpayerにデフォルト設定されます。
• Bot Taxの動作: Bot Taxが有効で別のガードがミントを拒否した場合、トランザクションはオンチェーンで成功しますがNFTは作成されません。ボット税のSOL額がCandy Machineアカウントに転送されます。Bot Taxがアクティブな場合は、ミント後に常にNFTの作成を確認してください。
• Config Line順序: Core Candy MachineがConfig Line Settingsを使用しisSequentialがfalseに設定されている場合、ミントされたアイテムは残りのプールからランダムに選択されます。trueに設定すると、順序通りにミントされます。
• ガードグループラベル必須: ガードグループが設定されている場合、groupパラメータは必須です。省略するとmint命令が失敗します。

FAQ

Candy Guardプログラム経由のミントとCore Candy Machineプログラムからの直接ミントの違いは何ですか？

Candy Guardプログラム経由のミントでは、設定されたガードを満たす限り誰でもミントでき、支払い、許可リスト、開始日などの複雑なアクセス制御ワークフローが可能です。Core Candy Machineプログラムからの直接ミントはすべてのガードをバイパスしますが、設定されたミント権限がトランザクションに署名する必要があり、権限制御のミントにのみ適しています。

複数のガードでミントする際にコンピュートユニット制限を増やすにはどうすればよいですか？

トランザクションビルダー内で@metaplex-foundation/mpl-toolboxのsetComputeUnitLimitヘルパーを使用します。300_000ユニットが一般的な出発点ですが、設定されたガードの数に基づいて調整する必要があります。ガードが多いほど、より多くのコンピュートユニットが必要です。

ミントが失敗してBot Taxが有効な場合はどうなりますか？

Bot Taxが有効で別のガードがミントを拒否した場合、トランザクションはオンチェーンで成功しますがNFTは作成されません。代わりに、設定されたボット税額（SOL）がミンターからCandy Machineアカウントに転送されます。この設計により、失敗した試行にもSOLがかかるため、ボットがガード条件を安価に調査することを防ぎます。

ミント時にすべてのガードにMint Settingsを提供する必要がありますか？

いいえ。追加のランタイム情報を必要とするガードのみがMint Settingsを必要とします。例えば、Third Party Signerは署名者参照を必要とし、Mint LimitはIDを必要とします。Start DateやEnd Dateなどのガードは自動的に検証され、Mint Settingsは不要です。各ガードのドキュメントページでMint Settingsが必要かどうかが指定されています。

minter署名者とpayer署名者の違いは何ですか？

Candy Guard v1.0から、mintV1命令は別々のminterとpayer署名者を受け取ります。payerはストレージやSOL支払いガードなどのSOLベースの手数料をカバーします。minterはガード条件（許可リストやミント制限など）に対して検証され、トークンベースの手数料を支払います。この分離により、バックエンドのpayerがエンドユーザーに代わってSOLコストをカバーするガスレスミントワークフローが可能になります。

次のステップ

興味があるかもしれない追加の読み物リソースは次のとおりです：

• 利用可能なすべてのガード: 必要なガードを厳選できるよう、利用可能なすべてのガードを確認してください。
• ガードグループ: 異なるミントフェーズのために複数のガードグループを設定する方法を学びます。
• Route命令: ガードが事前検証のためにroute命令を使用する方法を理解します。