Como a Compressão Funciona

Compressão de estado armazena um grande conjunto de registros como folhas em uma árvore de Merkle. Apenas o hash raiz (e nós de canopy opcionais) ficam on-chain; atualizadores fornecem 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 root

Quando usar:

• Entender por que transferências de cNFT precisam de proofs DAS
• Dimensionar árvores de Merkle concorrentes para capacidade de coleção
• Depurar transações Bubblegum com falha (proof obsoleto, raiz errada)
• Avaliar a dependência de indexador para seu produto

Exemplo Funcional

// Atualização conceitual de Merkle para transferência de folha
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("Raiz atual:", proof.root);
  console.log("Profundidade do proof:", proof.proof.length);
  console.log("Hash da folha:", proof.leaf);
  // Bubblegum verifica o proof contra a raiz da conta da árvore on-chain
  // então substitui a folha (propriedade) pelo novo hash
}

// Compressão de Conta SPL on-chain verifica o proof e aplica a substituição da folha
// Bubblegum envolve semânticas de metadados em torno das CPIs de compressão
// Programas raramente reimplementam a verificação de proof - delegue ao programa de compressão

O que isso demonstra:

• Comprimento do proof ≈ profundidade da árvore − profundidade do canopy
• A raiz on-chain deve corresponder à raiz do proof no momento da construção da transação
• O hash do conteúdo da folha codifica a propriedade da cNFT e os campos de metadados

Aprofundamento

Como Funciona

1. Criação da árvore aloca a conta Concurrent Merkle Tree com maxDepth e maxBufferSize escolhidos
2. Mint anexa o hash da folha no próximo índice; o programa verifica o proof de anexo
3. Transferência substitui os dados da folha (novo proprietário) com o proof de substituição
4. Canopy armazena nós superiores do proof on-chain para reduzir o tamanho da transação
5. Indexadores reconstroem o estado e servem proofs via DAS

On-Chain vs Off-Chain

Dimensionamento da Árvore

Escolha a profundidade para o suprimento máximo + margem; árvores mais profundas custam mais aluguel.

Armadilhas

• Proof obsoleto após mists concorrentes - a raiz mudou. Correção: obtenha um proof fresco imediatamente antes de assinar.
• Profundidade de árvore subdimensionada - não é possível fazer mint além da capacidade. Correção: planeje o suprimento máximo em createTree.
• Canopy zero em árvore profunda - tx muito grande. Correção: defina a profundidade do canopy de acordo com as recomendações da Metaplex para sua profundidade.
• Assumir folha na conta da carteira - não há conta de token SPL para cNFT. Correção: a propriedade é o estado da folha, lido via DAS.
• Auto-hospedagem de proofs sem indexador - infraestrutura pesada. Correção: use um provedor DAS ou execute um indexador de Merkle.

Alternativas

FAQs

Relacionado

• Noções Básicas de Compressão de Estado - introdução
• Lendo Ativos Comprimidos (DAS) - obtenção de proof
• Transferindo 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.