Como a Compressão Funciona
State compression armazena um grande conjunto de registros como folhas em uma merkle tree. Apenas o hash raiz (e nós canopy opcionais) ficam on-chain; quem atualiza fornece proofs de que uma mudança de folha é válida sem armazenar cada folha em uma conta Solana.
Receita
On-chain: MerkleTreeAccount { root, canopy[], change_log }
Off-chain: Full tree / leaf data indexed by provider
Per update: leaf + merkle proof + valid root transition
const proof = await dasRpc("getAssetProof", { id: assetId });
// proof.proof = sibling hashes from leaf to rootQuando usar:
- Entender por que transferências cNFT precisam de proofs DAS
- Dimensionar concurrent merkle trees para capacidade de coleção
- Depurar transações Bubblegum com falha (proof obsoleto, root errado)
- Avaliar dependência de indexer para seu produto
Exemplo Funcional
// Conceptual merkle update for leaf transfer
type MerkleProof = {
root: string;
proof: string[]; // sibling hashes bottom-up
node_index: number;
leaf: string;
};
async function explainProof(assetId: string) {
const proof = await dasRpc<MerkleProof>("getAssetProof", { id: assetId });
console.log("Current root:", proof.root);
console.log("Proof depth:", proof.proof.length);
console.log("Leaf hash:", proof.leaf);
// Bubblegum verifies proof against on-chain tree account root
// then replaces leaf (ownership) with new hash
}// On-chain SPL Account Compression verifies proof and applies leaf replace
// Bubblegum wraps metadata semantics around compression CPIs
// Programs rarely reimplement proof verification - delegate to compression programO que isso demonstra:
- Comprimento do proof ≈ profundidade da árvore − profundidade do canopy
- Root on-chain deve corresponder ao root do proof no build da transação
- Hash do conteúdo da folha codifica ownership e campos de metadata cNFT
Aprofundamento
Como Funciona
- Criação da árvore aloca conta Concurrent Merkle Tree com
maxDepthemaxBufferSizeescolhidos - Mint acrescenta hash de folha no próximo índice; programa verifica proof de append
- Transferência substitui dados da folha (novo owner) com replace proof
- Canopy armazena nós superiores de proof on-chain para reduzir tamanho da transação
- Indexers reconstruem estado e servem proofs via DAS
On-Chain vs Off-Chain
| Dado | Localização |
|---|---|
| Hash raiz | Conta de árvore on-chain |
| Nós canopy | Conta de árvore on-chain |
| Todas as folhas | Infraestrutura indexer / DAS |
| Proofs | Servidos por requisição pelo DAS |
Dimensionamento de Árvore
| maxDepth | Folhas máx (aprox) |
|---|---|
| 14 | 16,384 |
| 20 | 1,048,576 |
| 24 | 16,777,216 |
Escolha profundidade para pico de supply + margem; árvores mais profundas custam mais aluguel.
Armadilhas
- Proof obsoleto após mints concorrentes - root mudou. Correção: busque proof fresco imediatamente antes de assinar.
- Profundidade de árvore undersized - não pode mintar além da capacidade. Correção: planeje pico de supply em
createTree. - Canopy zero em árvore profunda - tx grande demais. Correção: defina profundidade de canopy por recomendações Metaplex para sua profundidade.
- Assumir folha em conta de carteira - sem conta de token SPL para cNFT. Correção: ownership é estado de folha, leia via DAS.
- Self-host de proofs sem indexer - infraestrutura pesada. Correção: use provider DAS ou execute indexer merkle.
Alternativas
| Alternativa | Use quando | Não use quando |
|---|---|---|
| NFT on-chain completo | Supply baixo, máxima composabilidade | Drop de milhão de itens |
| Só DB off-chain | Sem proveniência on-chain necessária | Precisa prova criptográfica de ownership |
| zk compression (outro) | Stack de produto diferente | Caminho padrão Metaplex cNFT |
FAQs
O que fica armazenado on-chain?
Hash merkle raiz, cache canopy, metadata de change log - não cada conta NFT.
O que é merkle proof?
Hashes irmãos provando inclusão de uma folha e permitindo atualizações verificadas.
Por que árvore concorrente?
Suporta múltiplas atualizações de folha por slot sem contenção global de lock da árvore.
O que é canopy?
Cache on-chain de nós superiores da árvore reduzindo tamanho de proof nas transações.
Quem serve proofs?
Providers RPC com DAS indexam árvores e expõem getAssetProof.
Proofs podem ser forjados?
Programa Bubblegum/compression verifica contra root on-chain - proofs inválidos falham.
Root muda quando?
A cada mint, transferência, burn atualizando uma folha.
IDs de programa?
Compression: cmtDvXnzBMY46rZyrBGX7p7r4Xc78DGpXEC5rVjrvAf. Bubblegum: BGUMAp9Gq7iN3nEkgqX1FbwwdBonfLCEEgxoj36SYPk.
Posso ler folha sem DAS?
Teoricamente via indexer customizado ingerindo logs do programa compression - DAS é padrão de produção.
Limites de tamanho de proof?
Impulsionam tamanho de tx - ajuste de canopy e transações versionadas com ALTs ajudam.
Burn de asset comprimido?
Replace de folha para estado null/burn com proof - instrução burn Bubblegum.
Árvores devnet?
Mesma mecânica na devnet; verifique suporte DAS devnet no seu provider.
Relacionado
- State Compression Basics - intro
- Reading Compressed Assets (DAS) - busca de proof
- Transferring cNFTs - proofs em txs
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.