NFT et Metaplex

Les jetons non fongibles (NFT) constituent l’une des applications les plus visibles de la blockchain aupres du grand public. Sur Solana, la conception des NFT repose sur une decision architecturale elegante : plutot que d’inventer un standard de contrat entierement nouveau comme l’ERC-721 d’Ethereum, Solana traite un NFT comme un simple jeton SPL dont le supply est fixe a 1 et les decimals a 0. Cette approche minimaliste s’inscrit dans la philosophie du modele de comptes de Solana, ou les donnees et la logique sont separees, et ou la composition entre programmes est privilegiee.

Le protocole Metaplex a emerge comme le standard de facto pour enrichir ces jetons bruts avec des metadonnees structurees. En ajoutant des comptes derives (PDA) qui stockent le nom, le symbole, l’URI vers les donnees hors chaine, les createurs et les royalties, Metaplex transforme un jeton SPL anonyme en un actif numerique identifiable, commercialisable et composable. L’ecosysteme NFT de Solana — des collections generatives aux billets d’evenements en passant par les actifs de jeux — repose presque entierement sur cette infrastructure.

Ce chapitre decortique l’architecture des NFT sur Solana, du jeton SPL sous-jacent jusqu’aux innovations recentes comme les compressed NFTs (cNFTs). Nous examinerons le standard Token Metadata de Metaplex, la creation d’un NFT avec Anchor, le mecanisme des collections, et la revolution des cNFTs qui reduisent le cout de frappe d’un facteur 1000. L’objectif est de comprendre les decisions de conception qui sous-tendent ce systeme, pas seulement d’en connaitre les mecaniques.

Qu’est-ce qu’un NFT sur Solana ?

Sur Solana, un NFT n’est pas un type de jeton special. C’est un jeton SPL ordinaire, soumis aux memes regles que n’importe quel autre jeton du Token Program, mais configure de maniere a le rendre unique et indivisible.

Définition 107 (NFT (Non-Fungible Token))

Un NFT (Non-Fungible Token) sur Solana est un jeton SPL dont le Mint Account est configure avec :

• supply = 1 : un seul exemplaire du jeton existe.

• decimals = 0 : le jeton est indivisible — on ne peut pas en posseder une fraction.

• mint_authority = None : l’autorite de frappe est revoquee apres la creation du premier et unique exemplaire, garantissant qu’aucun autre jeton ne pourra jamais etre cree a partir de ce mint.

Formellement, si \(M\) designe le Mint Account d’un NFT, alors :

\[ M.\text{supply} = 1, \quad M.\text{decimals} = 0, \quad M.\text{mint\_authority} = \varnothing \]

Ces trois contraintes suffisent a rendre le jeton non fongible : il est unique (un seul exemplaire), indivisible (pas de fractions) et immuable en quantite (pas de nouveau minting possible).

La non-fongibilite d’un NFT sur Solana repose donc sur la configuration du jeton, pas sur un programme distinct. Cette approche presente un avantage considerable : tous les outils, wallets et programmes qui interagissent avec les jetons SPL fonctionnent automatiquement avec les NFT, sans adaptation.

Cependant, un jeton SPL seul ne porte aucune information descriptive. Pour qu’un NFT ait un nom, une image, des attributs ou des royalties, il faut des comptes supplementaires. C’est ici qu’intervient l’architecture a trois comptes.

Définition 108 (Architecture a trois comptes d’un NFT)

Un NFT complet sur Solana est compose de trois comptes on-chain :

1. Mint Account : gere par le Token Program. Contient supply, decimals, mint_authority et freeze_authority. C’est le jeton lui-meme.

2. Metadata Account : gere par le Token Metadata Program de Metaplex. C’est un PDA derive de l’adresse du mint. Contient le nom, le symbole, l’URI vers les metadonnees hors chaine, le tableau des createurs, les royalties (seller_fee_basis_points) et le champ de collection.

3. Master Edition Account : gere par le Token Metadata Program. Egalement un PDA derive du mint. Controle l’impression (printing) : si max_supply = Some(0), le NFT est un exemplaire unique (one-of-one). Si max_supply = Some(n), il est possible d’imprimer \(n\) copies (editions).

Les deux PDA sont derives de maniere deterministe a partir de l’adresse du mint, ce qui permet a tout programme de les retrouver sans stockage supplementaire.

Remarque 76 (Difference avec Ethereum ERC-721)

Sur Ethereum, le standard ERC-721 definit un contrat intelligent unique qui maintient un mapping interne tokenId -> owner. Toutes les metadonnees, la logique de transfert et les royalties sont gerees par ce contrat. Le jeton n’existe pas independamment du contrat qui l’a cree.

Sur Solana, l’approche est radicalement differente :

• Le jeton est un SPL token standard, gere par le Token Program (un programme systeme partage par tout l’ecosysteme).

• Les metadonnees sont dans un compte separe, gere par le Token Metadata Program de Metaplex.

• La logique d’edition est dans un troisieme compte, egalement gere par Metaplex.

Cette separation des preoccupations (separation of concerns) signifie que le transfert d’un NFT utilise exactement la meme instruction que le transfert d’un jeton fongible. Les wallets, les explorateurs et les DEX n’ont pas besoin de cas particuliers pour les NFT. En contrepartie, comprendre la structure d’un NFT Solana necessite de comprendre les relations entre ces trois comptes — une complexite architecturale que ce chapitre vise a demystifier.

Le standard Metaplex Token Metadata

Le Token Metadata Program de Metaplex est le programme le plus utilise de l’ecosysteme Solana apres le Token Program et le System Program. Il ajoute une couche semantique aux jetons SPL en leur associant des metadonnees structurees.

Définition 109 (Token Metadata Program)

Le Token Metadata Program est un programme on-chain developpe par Metaplex (adresse : metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s). Il gere la creation et la mise a jour des comptes de metadonnees associes aux jetons SPL. Pour chaque mint, il peut creer :

• Un Metadata Account (PDA derive avec les seeds ["metadata", program_id, mint]) contenant les informations descriptives du jeton.

• Un Master Edition Account (PDA derive avec les seeds ["metadata", program_id, mint, "edition"]) contenant les contraintes d’impression.

Le programme definit les regles de mise a jour : seule l”update authority peut modifier les metadonnees, et les createurs doivent signer pour etre verifies.

Le compte Metadata contient les champs suivants :

Champ	Type	Description
key	u8	Type de compte (discriminateur)
update_authority	Pubkey	Autorite pouvant modifier les metadonnees
mint	Pubkey	Adresse du Mint Account associe
name	String	Nom du NFT (max 32 caracteres)
symbol	String	Symbole (max 10 caracteres)
uri	String	URI vers le JSON hors chaine (max 200 caracteres)
seller_fee_basis_points	u16	Royalties en points de base (500 = 5 %)
creators	Vec<Creator>	Tableau des createurs (adresse, part, verifie)
collection	Option<Collection>	Collection a laquelle le NFT appartient
uses	Option<Uses>	Compteur d’utilisations (billetterie, etc.)

````{prf:remark} Royalties et seller_fee_basis_points :label: ch12-rem-royalties

Le champ seller_fee_basis_points exprime les royalties en points de base : 1 point de base = 0,01 %. Ainsi, une valeur de 500 signifie 5 % de royalties. Lors d’une revente sur une marketplace, ce pourcentage est preleve sur le prix de vente et reparti entre les createurs selon les parts definies dans le tableau creators.

Il est important de noter que les royalties sur Solana ne sont pas imposees au niveau du protocole. Le Token Program ne connait pas la notion de royalties — c’est un mecanisme purement conventionnel, respecte par les marketplaces volontaires. Certaines marketplaces comme Magic Eden ont rendu les royalties optionnelles, ce qui a provoque un debat intense dans l’ecosysteme et conduit Metaplex a introduire les programmable NFTs (pNFTs) avec des regles de transfert imposees au niveau du programme.

L'URI pointe vers un fichier JSON heberge hors chaine (Arweave, IPFS, ou un serveur classique) qui contient les metadonnees detaillees. Ce JSON suit un schema standardise :

```json
{
  "name": "Solana Monkey #1234",
  "symbol": "SMB",
  "description": "Un singe genere de maniere procedurale sur la blockchain Solana.",
  "image": "https://arweave.net/abc123...xyz",
  "external_url": "https://solanamonkey.business",
  "attributes": [
    { "trait_type": "Background", "value": "Blue" },
    { "trait_type": "Fur", "value": "Golden" },
    { "trait_type": "Eyes", "value": "Laser" },
    { "trait_type": "Hat", "value": "Crown" }
  ],
  "properties": {
    "category": "image",
    "files": [
      {
        "uri": "https://arweave.net/abc123...xyz",
        "type": "image/png"
      }
    ],
    "creators": [
      {
        "address": "5K2...abc",
        "share": 100
      }
    ]
  }
}
```

````{prf:example} Lecture des metadonnees hors chaine
:label: ch12-ex-json-metadata

Le champ `uri` du Metadata Account pointe vers un fichier JSON comme celui presente ci-dessus. Un client (wallet, marketplace, explorateur) reconstruit l'affichage complet d'un NFT en deux etapes :

1. **Lecture on-chain** : recuperer le Metadata Account (PDA derive du mint) pour obtenir le nom, le symbole, l'URI et les createurs.
2. **Lecture off-chain** : effectuer une requete HTTP vers l'URI pour obtenir l'image, la description et les attributs detailles.

Le champ `attributes` du JSON hors chaine est particulierement important pour les collections generatives : il definit les **traits** (arriere-plan, fourrure, yeux, chapeau, etc.) qui determinent la rarete de chaque NFT. Les marketplaces utilisent ces attributs pour proposer des filtres de recherche et calculer des scores de rarete.

Remarque 77 (Donnees on-chain vs off-chain)

La repartition entre donnees on-chain et hors chaine est un compromis delibere. Stocker une image directement sur Solana couterait des dizaines de SOL en frais de rent — impraticable pour la plupart des projets. Le modele adopte par Metaplex place les informations essentielles on-chain (nom, symbole, createurs, royalties, URI) et delegue les donnees volumineuses (image, attributs detailles, fichiers) a un stockage hors chaine.

Le choix du stockage hors chaine a des implications sur la perennite :

• Arweave : stockage permanent avec paiement unique. Le plus utilise pour les NFT de valeur.

• IPFS : stockage distribue, mais necessite un pinning service pour garantir la disponibilite.

• Serveur HTTP : le moins fiable — si le serveur tombe, le NFT perd ses metadonnees.

La communaute Solana recommande fortement Arweave pour tout NFT destine a durer.

Définition 110 (Master Edition)

Le Master Edition Account controle la capacite d’un NFT a etre imprime en editions limitees. Il contient :

• supply : le nombre d’editions deja imprimees.

• max_supply : le nombre maximal d’editions autorisees.

  • Some(0) : le NFT est un exemplaire unique (one-of-one), aucune copie ne peut etre creee.

  • Some(n) : jusqu’a \(n\) editions peuvent etre imprimees.

  • None : nombre illimite d’editions (cas rare en pratique).

La creation du Master Edition Account revoque automatiquement le mint_authority du Mint Account, empechant tout minting supplementaire en dehors du mecanisme d’editions.

Visualisation de l’architecture NFT

Le diagramme suivant illustre les relations entre les differents comptes et les donnees hors chaine qui composent un NFT complet sur Solana.

Show code cell source

Hide code cell source

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

fig, ax = plt.subplots(figsize=(14, 8))

# --- Couleurs ---
colors = {
    "mint": "#9945FF",
    "metadata": "#14F195",
    "edition": "#00C2FF",
    "json": "#FF6B35",
    "image": "#E74C3C",
    "ata": "#F39C12",
}

# --- Dessiner les boites ---
box_style = dict(boxstyle="round,pad=0.6", linewidth=2)

# Mint Account
ax.text(2, 6.5, "Mint Account\n(Token Program)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["mint"], edgecolor="white", alpha=0.85),
        color="white")
ax.text(2, 5.6, "supply = 1\ndecimals = 0\nmint_authority = None", fontsize=8,
        ha="center", va="center", family="monospace",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="white", edgecolor=colors["mint"], alpha=0.9))

# Metadata Account
ax.text(7, 6.5, "Metadata Account\n(PDA)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["metadata"], edgecolor="white", alpha=0.85),
        color="black")
ax.text(7, 5.3, "name, symbol, uri\ncreators[], royalties\ncollection, uses", fontsize=8,
        ha="center", va="center", family="monospace",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="white", edgecolor=colors["metadata"], alpha=0.9))

# Master Edition Account
ax.text(12, 6.5, "Master Edition\n(PDA)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["edition"], edgecolor="white", alpha=0.85),
        color="white")
ax.text(12, 5.6, "supply = 0\nmax_supply = Some(0)", fontsize=8,
        ha="center", va="center", family="monospace",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="white", edgecolor=colors["edition"], alpha=0.9))

# Off-chain JSON
ax.text(7, 3.0, "JSON hors chaine\n(Arweave / IPFS)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["json"], edgecolor="white", alpha=0.85),
        color="white")
ax.text(7, 2.0, "name, description\nimage, attributes\nproperties, files", fontsize=8,
        ha="center", va="center", family="monospace",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="white", edgecolor=colors["json"], alpha=0.9))

# Image
ax.text(12, 3.0, "Image / Media\n(Arweave)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["image"], edgecolor="white", alpha=0.85),
        color="white")

# Token Account (ATA)
ax.text(2, 3.0, "Token Account\n(ATA du proprietaire)", fontsize=11, fontweight="bold",
        ha="center", va="center",
        bbox=dict(**box_style, facecolor=colors["ata"], edgecolor="white", alpha=0.85),
        color="white")
ax.text(2, 2.1, "amount = 1\nowner = wallet", fontsize=8,
        ha="center", va="center", family="monospace",
        bbox=dict(boxstyle="round,pad=0.4", facecolor="white", edgecolor=colors["ata"], alpha=0.9))

# --- Fleches ---
arrow_props = dict(arrowstyle="-|>", color="#555555", lw=1.8)

# Mint -> Metadata (PDA derivation)
ax.annotate("", xy=(5.0, 6.5), xytext=(3.8, 6.5), arrowprops=arrow_props)
ax.text(4.4, 6.85, "PDA", fontsize=8, ha="center", color="#555555", fontstyle="italic")

# Mint -> Master Edition (PDA derivation)
ax.annotate("", xy=(10.2, 6.5), xytext=(8.8, 6.5), arrowprops=arrow_props)
ax.text(9.5, 6.85, "PDA", fontsize=8, ha="center", color="#555555", fontstyle="italic")

# Metadata -> JSON (URI)
ax.annotate("", xy=(7, 3.7), xytext=(7, 4.6), arrowprops=arrow_props)
ax.text(7.5, 4.15, "uri", fontsize=8, ha="center", color="#555555", fontstyle="italic")

# JSON -> Image
ax.annotate("", xy=(10.2, 3.0), xytext=(8.8, 3.0), arrowprops=arrow_props)
ax.text(9.5, 3.3, "image", fontsize=8, ha="center", color="#555555", fontstyle="italic")

# Mint -> ATA
ax.annotate("", xy=(2, 3.75), xytext=(2, 4.95), arrowprops=arrow_props)
ax.text(2.5, 4.35, "mint ref", fontsize=8, ha="center", color="#555555", fontstyle="italic")

# --- Zones ---
# On-chain zone
on_chain_rect = plt.Rectangle((0.3, 4.8), 13.4, 2.7, linewidth=1.5,
                                edgecolor="#555555", facecolor="#f0f0f0",
                                alpha=0.15, linestyle="--", zorder=0)
ax.add_patch(on_chain_rect)
ax.text(0.6, 7.3, "ON-CHAIN", fontsize=9, fontweight="bold", color="#555555",
        fontstyle="italic")

# Off-chain zone
off_chain_rect = plt.Rectangle((0.3, 1.3), 13.4, 2.7, linewidth=1.5,
                                 edgecolor="#555555", facecolor="#fff3e0",
                                 alpha=0.15, linestyle="--", zorder=0)
ax.add_patch(off_chain_rect)
ax.text(0.6, 3.85, "OFF-CHAIN", fontsize=9, fontweight="bold", color="#555555",
        fontstyle="italic")

# --- Legende ---
legend_elements = [
    mpatches.Patch(facecolor=colors["mint"], label="Mint Account"),
    mpatches.Patch(facecolor=colors["metadata"], label="Metadata Account"),
    mpatches.Patch(facecolor=colors["edition"], label="Master Edition"),
    mpatches.Patch(facecolor=colors["json"], label="JSON hors chaine"),
    mpatches.Patch(facecolor=colors["image"], label="Image / Media"),
    mpatches.Patch(facecolor=colors["ata"], label="Token Account (ATA)"),
]
ax.legend(handles=legend_elements, loc="lower right", fontsize=9, framealpha=0.9)

ax.set_xlim(0, 14)
ax.set_ylim(1.0, 7.8)
ax.set_title("Architecture d'un NFT sur Solana", fontsize=14, fontweight="bold")
ax.axis("off")
plt.show()

Creation d’un NFT avec Anchor

La creation d’un NFT avec Anchor implique plusieurs etapes orchestrees par des Cross-Program Invocations (CPI) vers le Token Program et le Token Metadata Program de Metaplex. Le programme Anchor joue le role de chef d’orchestre : il coordonne la creation du mint, le minting du jeton, et la creation des comptes de metadonnees et d’edition.

use anchor_lang::prelude::*;
use anchor_spl::token::{self, Mint, MintTo, Token, TokenAccount};
use anchor_spl::associated_token::AssociatedToken;
use mpl_token_metadata::instructions::{
    CreateMetadataAccountV3CpiBuilder,
    CreateMasterEditionV3CpiBuilder,
};

declare_id!("NFT1111111111111111111111111111111111111111");

#[program]
pub mod nft_minter {
    use super::*;

    pub fn mint_nft(
        ctx: Context<MintNft>,
        name: String,
        symbol: String,
        uri: String,
    ) -> Result<()> {
        // 1. Mint 1 token vers l'ATA du createur
        let cpi_ctx = CpiContext::new(
            ctx.accounts.token_program.to_account_info(),
            MintTo {
                mint: ctx.accounts.mint.to_account_info(),
                to: ctx.accounts.token_account.to_account_info(),
                authority: ctx.accounts.payer.to_account_info(),
            },
        );
        token::mint_to(cpi_ctx, 1)?;

        // 2. Creer le Metadata Account via CPI
        CreateMetadataAccountV3CpiBuilder::new(
            &ctx.accounts.token_metadata_program,
        )
        .metadata(&ctx.accounts.metadata)
        .mint(&ctx.accounts.mint.to_account_info())
        .mint_authority(&ctx.accounts.payer)
        .payer(&ctx.accounts.payer)
        .update_authority(&ctx.accounts.payer, true)
        .system_program(&ctx.accounts.system_program)
        .name(name)
        .symbol(symbol)
        .uri(uri)
        .seller_fee_basis_points(500) // 5 % de royalties
        .invoke()?;

        // 3. Creer le Master Edition Account via CPI
        CreateMasterEditionV3CpiBuilder::new(
            &ctx.accounts.token_metadata_program,
        )
        .edition(&ctx.accounts.master_edition)
        .mint(&ctx.accounts.mint.to_account_info())
        .update_authority(&ctx.accounts.payer)
        .mint_authority(&ctx.accounts.payer)
        .metadata(&ctx.accounts.metadata)
        .payer(&ctx.accounts.payer)
        .token_program(&ctx.accounts.token_program)
        .system_program(&ctx.accounts.system_program)
        .max_supply(0) // One-of-one : aucune edition possible
        .invoke()?;

        msg!("NFT cree avec succes !");
        Ok(())
    }
}

#[derive(Accounts)]
pub struct MintNft<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,

    #[account(
        init,
        payer = payer,
        mint::decimals = 0,
        mint::authority = payer,
        mint::freeze_authority = payer,
    )]
    pub mint: Account<'info, Mint>,

    #[account(
        init,
        payer = payer,
        associated_token::mint = mint,
        associated_token::authority = payer,
    )]
    pub token_account: Account<'info, TokenAccount>,

    /// CHECK: PDA verifie par le Token Metadata Program
    #[account(mut)]
    pub metadata: UncheckedAccount<'info>,

    /// CHECK: PDA verifie par le Token Metadata Program
    #[account(mut)]
    pub master_edition: UncheckedAccount<'info>,

    pub token_program: Program<'info, Token>,
    pub associated_token_program: Program<'info, AssociatedToken>,
    pub system_program: Program<'info, System>,
    pub rent: Sysvar<'info, Rent>,

    /// CHECK: Programme Metaplex Token Metadata
    pub token_metadata_program: UncheckedAccount<'info>,
}

Remarque 78 (Complexite des CPI pour le minting de NFT)

La creation d’un NFT necessite des CPI vers au minimum trois programmes distincts :

1. System Program : pour creer et allouer les comptes (mint, ATA).

2. Token Program : pour initialiser le mint (decimals=0) et frapper (mint_to) un exemplaire.

3. Token Metadata Program : pour creer le Metadata Account et le Master Edition Account.

Chaque CPI implique la verification des comptes, des signatures et des autorites. Une seule instruction mint_nft peut declencher plus de cinq CPI internes. Cette complexite est le prix de la composabilite : en utilisant des programmes partages plutot qu’un contrat monolithique, chaque composant reste reutilisable et auditable independamment.

Du point de vue des compute units, le minting d’un NFT consomme typiquement entre 200 000 et 400 000 CU (sur un budget par defaut de 200 000, une augmentation via ComputeBudgetProgram est necessaire).

````{prf:example} Contraintes de comptes pour mint_nft :label: ch12-ex-contraintes-comptes

Examinons les contraintes de la structure MintNft :

• mint : init cree un nouveau compte, mint::decimals = 0 garantit l’indivisibilite, mint::authority = payer donne au createur le droit de frapper. Anchor genere une keypair aleatoire pour ce compte.

• token_account : init avec associated_token::mint = mint cree l’ATA (Associated Token Account) du payeur pour ce mint specifique. L’ATA est un PDA derive de maniere deterministe, ce qui evite les doublons.

• metadata : marque UncheckedAccount car le PDA est verifie par le Token Metadata Program lors du CPI, pas par Anchor. L’adresse correcte est derivee cote client avec les seeds ["metadata", metadata_program_id, mint_pubkey].

• master_edition : meme logique, avec les seeds ["metadata", metadata_program_id, mint_pubkey, "edition"].

• payer : Signer car il doit signer la creation de tous les comptes et le minting.

La distinction entre comptes verifies par Anchor (Account<'info, Mint>) et comptes verifies par le programme cible (UncheckedAccount) reflete la frontiere de responsabilite entre les deux programmes.

## Collections

Dans les premiers temps des NFT sur Solana, il etait difficile de determiner si un NFT appartenait reellement a une collection donnee. N'importe qui pouvait creer un NFT avec le meme nom et symbole qu'un projet populaire. Le mecanisme de collections resout ce probleme en introduisant un lien verifiable entre un NFT et sa collection.

````{prf:definition} Collection NFT
:label: ch12-def-collection

Une **collection** sur Solana est elle-meme un NFT (avec Mint Account, Metadata Account et Master Edition Account) qui sert de point d'ancrage pour un groupe de NFT. Chaque NFT membre possede dans son Metadata Account un champ `collection` contenant :

- **`key`** : la cle publique du mint de la collection.
- **`verified`** : un booleen indiquant si l'appartenance a ete verifiee par l'autorite de la collection.

Seule l'**update authority** du NFT de collection peut apposer le statut `verified = true` sur un NFT membre. Ce mecanisme empeche les imposteurs de se rattacher frauduleusement a une collection existante.

La verification de collection est un processus en deux etapes. D’abord, lors du minting d’un NFT membre, le champ collection est renseigne avec la cle du mint de la collection, mais verified est false. Ensuite, une instruction separee, signee par l’autorite de la collection, passe verified a true.

use mpl_token_metadata::instructions::VerifyCollectionCpiBuilder;

pub fn verify_collection(ctx: Context<VerifyCol>) -> Result<()> {
    VerifyCollectionCpiBuilder::new(
        &ctx.accounts.token_metadata_program,
    )
    .metadata(&ctx.accounts.nft_metadata)
    .collection_authority(&ctx.accounts.collection_authority)
    .payer(&ctx.accounts.payer)
    .collection_mint(&ctx.accounts.collection_mint.to_account_info())
    .collection(&ctx.accounts.collection_metadata)
    .collection_master_edition_account(
        &ctx.accounts.collection_master_edition
    )
    .invoke()?;

    msg!("Collection verifiee !");
    Ok(())
}

#[derive(Accounts)]
pub struct VerifyCol<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,

    /// Autorite de la collection (doit signer)
    pub collection_authority: Signer<'info>,

    /// CHECK: Metadata du NFT a verifier
    #[account(mut)]
    pub nft_metadata: UncheckedAccount<'info>,

    /// Mint de la collection
    pub collection_mint: Account<'info, Mint>,

    /// CHECK: Metadata de la collection
    pub collection_metadata: UncheckedAccount<'info>,

    /// CHECK: Master Edition de la collection
    pub collection_master_edition: UncheckedAccount<'info>,

    /// CHECK: Programme Metaplex Token Metadata
    pub token_metadata_program: UncheckedAccount<'info>,
}

Remarque 79 (Importance des collections pour les marketplaces)

Les marketplaces NFT (Magic Eden, Tensor, etc.) filtrent les NFT par collection verifiee. Un NFT dont le champ collection.verified est false — ou dont le champ collection est absent — ne sera generalement pas affiche dans la page d’une collection, meme s’il porte le meme nom et le meme symbole.

Ce mecanisme est crucial pour la confiance dans l’ecosysteme :

• Les acheteurs savent qu’un NFT affiche dans une collection a ete autorise par l’equipe du projet.

• Les createurs peuvent proteger leur marque contre les contrefacons.

• Les marketplaces peuvent filtrer les NFT de maniere fiable sans avoir a maintenir des listes blanches manuelles.

En pratique, la verification de collection est devenue un prerequis pour tout projet NFT serieux sur Solana.

Compressed NFTs (cNFTs)

Les NFT classiques sur Solana coutent environ 0,01 SOL en frais de creation (rent pour les comptes). Pour une collection de 10 000 NFT, le cout atteint environ 100 SOL. Pour des collections de millions d’elements — actifs de jeux, billets d’evenements, programmes de fidelite — ce modele est economiquement intenable. Les compressed NFTs (cNFTs) resolvent ce probleme de maniere spectaculaire.

Définition 111 (Compressed NFT (cNFT))

Un Compressed NFT (cNFT) est un NFT dont les donnees ne sont pas stockees dans des comptes individuels on-chain, mais dans un arbre de Merkle (Merkle tree) gere par le programme de compression d’etat de Solana (State Compression Program). Seule la racine de Merkle est stockee on-chain dans un compte unique partage par tous les NFT de l’arbre.

Le cout de creation d’un cNFT est d’environ \(\frac{1}{1000}\) du cout d’un NFT classique :

\[ \text{Cout}(\text{cNFT}) \approx \frac{\text{Cout}(\text{NFT classique})}{1000} \approx 0{,}00001 \text{ SOL} \]

Cette reduction massive provient du fait qu’un seul compte on-chain (l’arbre de Merkle) peut contenir des millions de feuilles, chacune representant un NFT.

Le principe est le suivant. Au lieu de creer trois comptes on-chain par NFT (mint, metadata, master edition), les cNFTs encodent les donnees de chaque NFT dans une feuille de l’arbre de Merkle. Seul le hash racine de l’arbre est stocke on-chain. Les donnees detaillees de chaque NFT sont stockees hors chaine par des indexeurs (comme Helius, Triton, ou le DAS API).

Pour prouver qu’un NFT specifique existe et appartient a un proprietaire donne, on fournit une preuve de Merkle : le chemin de hashes depuis la feuille jusqu’a la racine. Si la preuve est valide, le NFT est authentique.

Show code cell source

Hide code cell source

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import networkx as nx
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

fig, ax = plt.subplots(figsize=(14, 7))

# --- Construction de l'arbre de Merkle ---
G = nx.DiGraph()

# Feuilles (niveau 0) : 8 NFTs
leaves = [f"NFT #{i}" for i in range(1, 9)]
level_0 = [(f"L{i}", {"label": leaves[i], "level": 0}) for i in range(8)]

# Niveau 1 : 4 noeuds internes
level_1 = [(f"N1_{i}", {"label": f"H({leaves[2*i][:5]}, {leaves[2*i+1][:5]})", "level": 1}) for i in range(4)]

# Niveau 2 : 2 noeuds internes
level_2 = [(f"N2_{i}", {"label": f"H(N1_{2*i}, N1_{2*i+1})", "level": 2}) for i in range(2)]

# Racine
root = [("Root", {"label": "Racine de Merkle\n(on-chain)", "level": 3})]

# Ajouter les noeuds
for node, attrs in level_0 + level_1 + level_2 + root:
    G.add_node(node, **attrs)

# Ajouter les aretes
for i in range(4):
    G.add_edge(f"N1_{i}", f"L{2*i}")
    G.add_edge(f"N1_{i}", f"L{2*i+1}")
for i in range(2):
    G.add_edge(f"N2_{i}", f"N1_{2*i}")
    G.add_edge(f"N2_{i}", f"N1_{2*i+1}")
G.add_edge("Root", "N2_0")
G.add_edge("Root", "N2_1")

# --- Positions manuelles ---
pos = {}
# Feuilles
for i in range(8):
    pos[f"L{i}"] = (i * 1.6, 0)
# Niveau 1
for i in range(4):
    pos[f"N1_{i}"] = (i * 3.2 + 0.8, 2)
# Niveau 2
for i in range(2):
    pos[f"N2_{i}"] = (i * 6.4 + 2.4, 4)
# Racine
pos["Root"] = (5.6, 6)

# --- Chemin de preuve pour NFT #3 (L2) ---
proof_path_nodes = {"L2", "L3", "N1_1", "N1_0", "N2_0", "N2_1", "Root"}
proof_path_edges = {("N1_1", "L2"), ("N1_1", "L3"), ("N2_0", "N1_0"),
                    ("N2_0", "N1_1"), ("Root", "N2_0"), ("Root", "N2_1")}
proof_highlight = {"L2", "N1_1", "N2_0", "Root"}  # Chemin direct
proof_sibling = {"L3", "N1_0", "N2_1"}  # Noeuds freres (preuve)

# --- Couleurs des noeuds ---
palette = sns.color_palette("muted")
node_colors = []
for node in G.nodes():
    if node in proof_highlight:
        node_colors.append("#E74C3C")  # Chemin de preuve
    elif node in proof_sibling:
        node_colors.append("#F39C12")  # Noeuds freres
    elif G.nodes[node]["level"] == 0:
        node_colors.append(palette[0])  # Feuilles
    else:
        node_colors.append(palette[2])  # Noeuds internes

# --- Couleurs des aretes ---
edge_colors = []
for u, v in G.edges():
    if (u, v) in proof_path_edges and u in proof_highlight and v in proof_highlight:
        edge_colors.append("#E74C3C")
    elif (u, v) in proof_path_edges and (v in proof_sibling or u in proof_sibling):
        edge_colors.append("#F39C12")
    else:
        edge_colors.append("#CCCCCC")

edge_widths = [2.5 if c != "#CCCCCC" else 1.2 for c in edge_colors]

# --- Dessin ---
nx.draw_networkx_edges(G, pos, ax=ax, edge_color=edge_colors, width=edge_widths,
                       arrows=False)
nx.draw_networkx_nodes(G, pos, ax=ax, node_color=node_colors, node_size=800,
                       edgecolors="white", linewidths=2)

# Labels
labels = {}
for node in G.nodes():
    if G.nodes[node]["level"] == 0:
        labels[node] = leaves[int(node[1:])]
    elif node == "Root":
        labels[node] = "Racine"
    else:
        labels[node] = node.replace("N", "H")

nx.draw_networkx_labels(G, pos, labels, ax=ax, font_size=8, font_weight="bold")

# Annotation pour la preuve
ax.annotate(
    "Preuve d'inclusion\npour NFT #3",
    xy=(pos["L2"][0], pos["L2"][1] + 0.3),
    xytext=(pos["L2"][0] - 2.5, pos["L2"][1] - 1.2),
    fontsize=10, ha="center", color="#E74C3C", fontweight="bold",
    arrowprops=dict(arrowstyle="->", color="#E74C3C", lw=1.5),
    bbox=dict(boxstyle="round,pad=0.4", facecolor="#FADBD8", edgecolor="#E74C3C")
)

# Legende
legend_elements = [
    mpatches.Patch(facecolor="#E74C3C", label="Chemin de verification"),
    mpatches.Patch(facecolor="#F39C12", label="Noeuds freres (preuve)"),
    mpatches.Patch(facecolor=palette[0], label="Feuilles (NFTs)"),
    mpatches.Patch(facecolor=palette[2], label="Noeuds internes"),
]
ax.legend(handles=legend_elements, loc="upper left", fontsize=9, framealpha=0.9)

ax.set_title("Arbre de Merkle pour Compressed NFTs : preuve d'inclusion",
             fontsize=13, fontweight="bold")
ax.axis("off")
plt.show()

Définition 112 (Bubblegum)

Bubblegum est le programme Metaplex dedie a la gestion des compressed NFTs (adresse : BGUMAp9Gq7iTEuizy4pqaxsTyUCBK68MDfK752saRPUY). Il sert d’interface de haut niveau au-dessus du State Compression Program et du Noop Program. Bubblegum permet de :

• Creer un arbre de Merkle (create_tree) avec une profondeur et une taille de canopy configurables.

• Frapper des cNFTs (mint_v1) en inserant une nouvelle feuille dans l’arbre.

• Transferer des cNFTs (transfer) en fournissant la preuve de Merkle du proprietaire actuel.

• Bruler des cNFTs (burn) en remplacant la feuille par un hash nul.

• Decompresser un cNFT (decompress_v1) en le convertissant en NFT classique avec des comptes individuels.

Le choix de la profondeur de l’arbre determine le nombre maximal de cNFTs : un arbre de profondeur \(d\) peut contenir \(2^d\) feuilles. Un arbre de profondeur 20 supporte environ 1 million de cNFTs.

Remarque 80 (Compromis des compressed NFTs)

Les cNFTs offrent une reduction de cout spectaculaire, mais introduisent des compromis importants :

Avantages :

• Cout de minting reduit d’un facteur ~1000 (quelques centimes pour des milliers de cNFTs).

• Meme garantie de propriete que les NFT classiques (la racine de Merkle est on-chain).

• Possibilite de decompresser un cNFT en NFT classique a tout moment.

Inconvenients :

• Dependance aux indexeurs : pour lire les donnees d’un cNFT ou construire une preuve de Merkle, il faut interroger un indexeur (Helius, Triton) via le DAS API. Si l’indexeur est indisponible, les donnees restent accessibles via les logs de transactions, mais c’est beaucoup plus lent.

• Transferts plus complexes : chaque transfert necessite une preuve de Merkle complete, ce qui augmente la taille de la transaction et la complexite cote client.

• Latence de l’indexation : apres un minting ou un transfert, il y a un delai (generalement quelques secondes) avant que l’indexeur mette a jour son etat.

• Canopy : pour reduire la taille des preuves on-chain, une partie de l’arbre de Merkle (le canopy) peut etre stockee on-chain, ce qui augmente le cout initial de creation de l’arbre.

Le choix entre NFT classique et cNFT depend du cas d’usage : pour une collection de 10 000 pieces d’art numerique de haute valeur, le NFT classique reste preferable (pas de dependance a un indexeur). Pour distribuer des millions de billets d’evenements ou d’actifs de jeux, les cNFTs sont la solution evidente.

Exemple 37 (Dimensionnement d’un arbre de cNFTs)

Pour creer une collection de 100 000 cNFTs, il faut dimensionner l’arbre de Merkle :

• Profondeur : \(\lceil \log_2(100\,000) \rceil = 17\) (un arbre de profondeur 17 supporte \(2^{17} = 131\,072\) feuilles).

• Max buffer size : typiquement 64 pour un arbre de cette taille (nombre de modifications concurrentes supportees).

• Canopy depth : 10 (stocke les 10 premiers niveaux de l’arbre on-chain, reduisant la taille des preuves de 17 a 7 hashes).

Le cout de creation de l’arbre (rent pour le compte) est d’environ 1,5 SOL — a comparer aux ~1 000 SOL necessaires pour creer 100 000 NFT classiques. Le minting de chaque cNFT ne coute ensuite que les frais de transaction (~5 000 lamports).

Resume

Ce chapitre a decortique l’architecture des NFT sur Solana, de la representation minimaliste (un jeton SPL avec supply=1, decimals=0) jusqu’aux innovations de compression qui bouleversent l’economie du minting.

Concept	Description
NFT	Jeton SPL avec supply=1 et decimals=0, rendu unique et indivisible
Architecture a 3 comptes	Mint Account + Metadata Account (PDA) + Master Edition Account (PDA)
Token Metadata Program	Programme Metaplex gerant les metadonnees on-chain des jetons
Master Edition	Controle l’impression d’editions ; max_supply=0 pour un one-of-one
Metadonnees off-chain	JSON sur Arweave/IPFS contenant image, attributs et proprietes
Collection	NFT servant de point d’ancrage pour un groupe, avec verification par l’autorite
Compressed NFT (cNFT)	NFT stocke dans un arbre de Merkle on-chain, ~1000x moins cher
Bubblegum	Programme Metaplex pour creer et gerer les cNFTs
Preuve de Merkle	Chemin cryptographique prouvant l’inclusion d’un cNFT dans l’arbre

Les decisions de conception revelent une philosophie coherente : reutiliser les primitives existantes (SPL tokens) plutot que d’inventer des standards ex nihilo, separer les preoccupations entre programmes specialises (Token Program, Metadata Program, Bubblegum), et optimiser agressivement les couts lorsque le cas d’usage l’exige (compression). Le chapitre suivant appliquera cette meme logique de composabilite aux pools de liquidite.