Compressed NFTs Explicados

Um compressed NFT (cNFT) é um ativo digital único cujo ownership e metadata vivem como hash de folha numa árvore Merkle, não como um conjunto completo de contas Solana pagando rent por item. A chain armazena uma conta de árvore pequena (root, canopy, changelog). Indexadores reconstruem folhas e servem provas para que carteiras e programas possam provar e atualizar um asset específico.

State compression é o padrão mais amplo: muitos registros compartilham uma árvore Merkle concorrente, e cada atualização prova que a folha nova é consistente com a root atual. Bubblegum é a camada NFT da Metaplex sobre o programa SPL Account Compression - mint, transfer, burn e vínculo de coleção em escala.

Esta página é o guarda-chuva de State Compression & cNFTs. Páginas irmãs aprofundam basics, mecânica de árvore, Bubblegum, DAS, transferências e custos.

Resumo

• cNFTs comprimem estado NFT por item em folhas Merkle sob uma árvore concorrente; integridade on-chain é uma root (e canopy), enquanto indexadores DAS guardam dados de folha e provas para leituras e mutações.
• Por que Importa: NFTs Token Metadata ou Core completos pagam rent por mint, metadata e contas relacionadas. Em dezenas de milhares a milhões de itens (inventários de jogos, POAPs, drops generativos grandes), esse rent domina. Compressão amortiza storage para que custo marginal de mint seja sobretudo taxas de transação.
• Conceitos Chave: State compression, árvore Merkle concorrente, folha / root / canopy, changelog / buffer, Bubblegum, API DAS, prova Merkle, leaf owner, tree authority.
• Quando Usar: Ativos únicos de alto volume onde rent por conta é proibitivo; airdrops em lote; credenciais de fidelidade ou presença; itens de jogo em escala 10k+ com requisitos leves de marketplace.
• Limitações / Trade-offs: Você depende de um indexador com DAS para UX de produção; transferências precisam de provas frescas e mais contas/CU que uma transferência simples de token; composabilidade on-chain (escrow, colateral DeFi) é mais fina que para NFTs baseados em conta completos.
• Tópicos Relacionados: State compression basics, how compression works, Bubblegum minting, DAS reading, transferring cNFTs, cost and trade-offs.

Fundamentos

O problema de rent que NFTs padrão criam

Na Solana, dados duráveis vivem em contas que devem permanecer rent-exempt. Um NFT Metaplex Token Metadata clássico tipicamente envolve mint, conta de token (ou ATA), metadata e muitas vezes contas de edition. Cada uma trava lamports para rent. Multiplique por 100.000 itens e o custo de capital vira decisão de produto.

cNFTs invertem esse modelo. Uma conta de árvore guarda estado resumido para até 2^maxDepth folhas. Cada mint insere (ou depois substitui) um hash de folha que compromete ownership e campos de metadata, em vez de uma nova conta de dados de longa duração. Você ainda hospeda JSON e mídia off-chain (Arweave, IPFS, HTTPS). O que muda é onde unicidade e prova de ownership vivem on-chain.

Árvores Merkle numa imagem

Uma árvore Merkle faz hash de pares de nós para cima até restar uma única root.

  Off-chain / indexer                     On-chain tree account
  --------------------                    ---------------------
  leaf_0  leaf_1  ... leaf_n              root hash
     \     /         /                    canopy (upper nodes, optional)
      h01 ...   ...                       changelog (recent roots)
         \     /
          root  <-----------------------> must match proof.root

Dado a root e um caminho de hashes irmãos (uma prova), você pode verificar que uma folha pertence à árvore sem armazenar toda folha on-chain.

State compression usa uma árvore Merkle concorrente para que múltiplas atualizações possam aterrissar sem tratar a árvore como estrutura single-writer. A conta mantém um changelog de roots recentes e um buffer dimensionado por maxBufferSize para que atualizações concorrentes de folha ainda possam verificar.

Canopy depth armazena nós de prova superiores na conta de árvore. Canopies mais profundos custam mais rent adiantado e encolhem as contas de prova que você deve passar na transferência. Esse trade-off é central no design de árvore de produção.

Bubblegum vs o programa de compressão

Program ids comuns (deployments Metaplex):

• Account Compression: cmtDvXnzBMY46rZyrBGX7p7r4Xc78DGpXEC5rVjrvAf
• Bubblegum: BGUMAp9Gq7iN3nEkgqX1FbwwdBonfLCEEgxoj36SYPk

Clientes costumam usar Metaplex Umi com mpl-bubblegum e mpl-account-compression para criar árvore e mint, com @solana/kit 7.0.0 para envios RPC gerais. Programas Anchor que integram cNFTs usam o mesmo modelo de prova; não inventam um segundo runtime de compressão.

Mapa de ciclo de vida

1. Criar árvore - escolher maxDepth, maxBufferSize e canopyDepth; pagar rent da árvore uma vez.
2. Mint - Bubblegum faz hash de metadata + owner numa folha e anexa via compressão.
3. Indexar - um provedor DAS materializa registros de asset e provas a partir de eventos.
4. Ler - carteiras chamam DAS (getAsset, searchAssets, getAssetsByGroup), não getAccountInfo por item.
5. Transferir / atualizar - cliente busca prova fresca, monta ix Bubblegum, verifica contra root viva, substitui a folha.

Integridade é on-chain (transições de root). Descoberta é off-chain (indexador). Produtos precisam dos dois.

Mecânica e Interações

Parâmetros de árvore que travam capacidade de produto

Na criação você fixa capacidade aproximadamente como 2^maxDepth folhas:

Você não redimensiona depth casualmente depois. Subdimensionar força segunda árvore, coleções divididas ou migração dolorosa. Planeje supply mais folga (muitas vezes 2x-4x), balanceado contra rent maior para árvores e canopies mais profundos.

maxBufferSize suporta atualizações concorrentes contra o changelog. canopyDepth encurta provas em transações. Árvores profundas sem canopy costumam estourar limites de tamanho de transação; canopy é como equipes mantêm transferências aterrissáveis.

O que uma folha compromete

Bubblegum define um formato de metadata comprimida (name, uri, seller fee, creators, campos de collection e hashes relacionados). Ownership é codificado com o leaf owner (e delegates opcionais). Mudar owner significa substituir o hash da folha para que o hash novo corresponda ao payload de ownership novo na mesma árvore.

Por isso transferências não são spl_token::transfer. Não há saldo clássico de token para debitar. A instrução prova "esta folha está na árvore sob root R" e instala uma folha nova no mesmo índice com compromisso de owner novo.

Por que DAS não é opcional em produção

RPC padrão responde "quais bytes esta conta guarda?" cNFTs não alocam uma conta por asset, e a conta de árvore não lista todo nome e imagem. Sem indexador que seguiu eventos de compressão e Bubblegum, uma carteira não pode listar inventário do owner nem montar prova válida.

A Digital Asset Standard (DAS) API é a superfície de leitura comum:

Provas ficam stale quando a root da árvore avança. Clientes devem refetch imediatamente antes de assinar. Cachear metadata com TTL é ok; cachear provas por minutos é modo de falha comum.

Fluxo de transferência ponta a ponta

  Wallet / dapp
       |
       | 1. getAsset(id) + getAssetProof(id)  --> DAS RPC
       |
       | 2. Build Bubblegum transfer ix
       |    - merkle tree, leaf owner signer, new leaf owner
       |    - root, data/creator hashes, nonce/index
       |    - proof nodes as remaining accounts
       v
  Bubblegum --> CPI verify + replace leaf
       v
  Account Compression --> root + changelog update
       v
  Indexer --> DAS state catches up

Modos de falha mapeiam para este caminho: root stale, ordem de prova errada, comprimento de prova ajustado por canopy faltando, limites de CU ou tamanho de tx, signer de leaf owner errado, ou lag de indexador que confunde "tx teve sucesso" com "galeria já atualizou."

Custos: onde o dinheiro se move

Adiantado: rent da árvore (depth, buffer, canopy). Por mint: taxas de transação (e priority fees sob contenção), não rent completo de conta por NFT. Contínuo: tiers DAS, engenharia de pipeline de provas, suporte de envio e CU maior que uma transferência Core simples.

Abaixo de algumas centenas de 1/1s de prestígio, Metaplex Core costuma ser mais simples. Em escala generativa ou de jogo multi-milhar, economia de rent de cNFT domina se você aceita dependência de indexador e UX de prova. Colateral DeFi e composição profunda de programa ainda favorecem padrões baseados em conta a menos que parceiros suportem fluxos comprimidos.

Clientes @solana/kit 7.0.0 ainda usam RPC ordinário para submit/confirm; DAS é superfície de método separada (muitas vezes a mesma URL do vendor). Valide CU e tamanho de tx em ferramentas Agave 4.1.1 / Solana CLI 3.0.10 antes de janelas de mint mainnet.

Considerações Avançadas e Aplicações

Escolhas de arquitetura que envelhecem bem

Tree authority é segurança operacional. Compromisso da autoridade de mint ou árvore é incidente de coleção inteira. Use multisig ou autoridades de programa bem governadas.

Vínculo de coleção ainda importa para marketplaces e getAssetsByGroup. Planeje fluxos de verificação de coleção antes de mint em massa para que agrupamento DAS funcione no dia um.

Janelas de mint em lote precisam de priority fees, envio consciente de rate e monitoramento de lag. Mint on-chain bem-sucedido invisível no DAS por minutos é ticket de suporte, não bug da chain.

Composabilidade e design de programa

Programas que fazem escrow ou roteiam cNFTs devem falar contas Bubblegum e compressão, não transferência Token Program. Contas de prova inflam listas de remaining-accounts. Sob Agave 4.1.1, verificação de prova aninhada é mais pesada que uma única transferência SPL. Prefira SDKs validados a verificação de prova feita à mão.

Se você precisa de colateral DeFi ou CPI profundo em protocolos de terceiros, valide suporte de parceiros antes de escolher cNFT. Compressão otimiza economia de storage, não composabilidade universal.

Observabilidade e modos de falha

Acompanhe três relógios:

1. Tempo da chain - transação aterrissou e root avançou.
2. Tempo do indexador - DAS reflete a folha nova.
3. Tempo do cliente - prova para a próxima ação ainda é válida contra a root.

Telemetria deve cobrir falhas de fetch de prova, falhas de simulação de transferência (root stale), lag DAS após rajadas de mint e preenchimento da árvore vs 2^maxDepth. Alerte bem antes da última folha.

Evolução da stack

State compression generalizou "faça hash de muitas coisas, armazene a root." Bubblegum especializou isso para metadata NFT. DAS padronizou leituras de carteira para digital assets. Separe caminho de escrita (Bubblegum + compressão + RPC ordinário) de caminho de leitura (DAS) em config, retries e SLAs - mesmo enquanto Umi, kit e clientes Anchor 0.32.1 melhoram ergonomia.

Equívocos Comuns

• "cNFTs são NFTs grátis." Rent de árvore, taxas, assinaturas DAS e engenharia de prova são reais. Você economiza rent de conta por item, não todo custo.
• "Posso ler um cNFT com getAccountInfo no asset id." Não há conta de dados completa por item. Use DAS getAsset e métodos relacionados.
• "Uma prova é permanente como chave privada." Provas são válidas relativas a uma root. Mints e transferências concorrentes as invalidam rapidamente.
• "Compressão significa metadata totalmente on-chain." A chain compromete hashes e ownership; mídia e JSON ainda ficam off-chain na URI na folha.
• "Qualquer marketplace ou protocolo DeFi vai funcionar." Muitas integrações assumem NFTs baseados em conta. Confirme suporte comprimido explicitamente.
• "Posso expandir depth da árvore depois se viralizar." Depth é decisão na criação. Planeje folga ou estratégia multi-árvore adiantado.
• "RPC vanilla sem DAS é ok se eu guardar folhas no meu DB." Você vira o indexador: disponibilidade, reorgs, correção de prova e UX multi-carteira caem em você.

FAQs

Relacionado

• State Compression Basics - primeiro vocabulário e exemplos iniciais para árvores e cNFTs
• How Compression Works - roots, provas, canopy e mecânica de dimensionamento de árvore
• Compressed NFTs (Bubblegum) - createTree, mintV1 e pipelines de mint em escala
• Reading Compressed Assets (DAS) - getAsset, getAssetProof e queries de galeria
• Transferring cNFTs - mudanças de ownership baseadas em prova ponta a ponta
• Cost & Trade-offs - quando compressão vence versus Core ou Token Metadata

Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.