Compressão ZK

Canopy (Merkle Tree)

The canopy is an optional on-chain cache of the upper N levels of a Concurrent Merkle Tree's nodes, stored within the CMT account itself, which eliminates the need for clients to pass those N levels as part of their Merkle proof in transactions, thereby reducing transaction size and cost. A canopy of depth D means the top D levels of the tree (2^D - 1 nodes) are always available on-chain; for a depth-20 tree with a canopy of 14, clients only need to supply 6 sibling hashes rather than 20, saving approximately 448 bytes of transaction data per instruction. Storing a deeper canopy increases the CMT account's rent-exempt balance linearly but makes interactions cheaper in compute units and transaction space, so selecting the optimal canopy depth is a cost trade-off for tree designers.

IDcanopy

Leitura rápida

Comece pela explicação mais curta e útil antes de aprofundar.

The canopy is an optional on-chain cache of the upper N levels of a Concurrent Merkle Tree's nodes, stored within the CMT account itself, which eliminates the need for clients to pass those N levels as part of their Merkle proof in transactions, thereby reducing transaction size and cost. A canopy of depth D means the top D levels of the tree (2^D - 1 nodes) are always available on-chain; for a depth-20 tree with a canopy of 14, clients only need to supply 6 sibling hashes rather than 20, saving approximately 448 bytes of transaction data per instruction. Storing a deeper canopy increases the CMT account's rent-exempt balance linearly but makes interactions cheaper in compute units and transaction space, so selecting the optimal canopy depth is a cost trade-off for tree designers.

Modelo mental

Use primeiro a analogia curta para raciocinar melhor sobre o termo quando ele aparecer em código, docs ou prompts.

Pense nisso como um bloco de construção que ajuda a ligar uma definição isolada ao sistema maior onde ela vive.

Contexto técnico

Coloque o termo dentro da camada de Solana em que ele vive para raciocinar melhor sobre ele.

Estado comprimido, provas e padrões de armazenamento voltados a escala.

Por que builders ligam para isso

Transforme o termo de vocabulário em algo operacional para produto e engenharia.

Este termo destrava conceitos adjacentes rapidamente, então funciona melhor quando você o trata como um ponto de conexão, não como definição isolada.

Handoff para IA

Handoff para IA

Use este bloco compacto quando quiser dar contexto aterrado para um agente ou assistente sem despejar a página inteira.

Canopy (Merkle Tree) (canopy)
Categoria: Compressão ZK
Definição: The canopy is an optional on-chain cache of the upper N levels of a Concurrent Merkle Tree's nodes, stored within the CMT account itself, which eliminates the need for clients to pass those N levels as part of their Merkle proof in transactions, thereby reducing transaction size and cost. A canopy of depth D means the top D levels of the tree (2^D - 1 nodes) are always available on-chain; for a depth-20 tree with a canopy of 14, clients only need to supply 6 sibling hashes rather than 20, saving approximately 448 bytes of transaction data per instruction. Storing a deeper canopy increases the CMT account's rent-exempt balance linearly but makes interactions cheaper in compute units and transaction space, so selecting the optimal canopy depth is a cost trade-off for tree designers.
Relacionados: Concurrent Merkle Tree, Proof Path
Glossary Copilot

Faça perguntas de Solana com contexto aterrado sem sair do glossário.

Use contexto do glossário, relações entre termos, modelos mentais e builder paths para receber respostas estruturadas em vez de output genérico.

Explicar este código

Opcional: cole código Anchor, Solana ou Rust para o Copilot mapear primitivas de volta para termos do glossário.

Faça uma pergunta aterrada no glossário

Faça uma pergunta aterrada no glossário

O Copilot vai responder usando o termo atual, conceitos relacionados, modelos mentais e o grafo ao redor do glossário.

Grafo conceitual

Veja o termo como parte de uma rede, não como uma definição sem saída.

Esses ramos mostram quais conceitos esse termo toca diretamente e o que existe uma camada além deles.

Ramo

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.

Ramo

Proof Path

A proof path is the ordered sequence of sibling node hashes that constitute a Merkle proof, tracing a route from a specific leaf node up to the tree root by providing the hash of each sibling at every level of the tree. In Solana's compressed account and compressed NFT transactions, the proof path is passed as a list of additional accounts (each account holding a 32-byte hash) in the instruction's account metas, since proof nodes exceed what can fit in instruction data alone for deep trees. The length of the proof path equals tree_depth minus canopy_depth, so indexers like Photon pre-compute and serve proof paths to clients, which can then submit them directly to on-chain programs for verification.

Próximos conceitos para explorar

Continue a cadeia de aprendizado em vez de parar em uma única definição.

Estes são os próximos conceitos que valem abrir se você quiser que este termo faça mais sentido dentro de um workflow real de Solana.

Compressão ZK

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.

Compressão ZK

Proof Path

A proof path is the ordered sequence of sibling node hashes that constitute a Merkle proof, tracing a route from a specific leaf node up to the tree root by providing the hash of each sibling at every level of the tree. In Solana's compressed account and compressed NFT transactions, the proof path is passed as a list of additional accounts (each account holding a 32-byte hash) in the instruction's account metas, since proof nodes exceed what can fit in instruction data alone for deep trees. The length of the proof path equals tree_depth minus canopy_depth, so indexers like Photon pre-compute and serve proof paths to clients, which can then submit them directly to on-chain programs for verification.

Compressão ZK

Canopy Depth

The number of top levels of a Concurrent Merkle Tree that are cached on-chain within the CMT account, reducing the Merkle proof size that clients must include in transactions. A canopy depth of D means the top D levels (2^D - 1 nodes) are stored on-chain, so clients only need to supply (tree_depth - D) sibling hashes instead of the full tree_depth. Deeper canopies reduce transaction size and compute costs but increase the CMT account's rent-exempt balance. Choosing optimal canopy depth is a cost trade-off between on-chain storage rent and per-transaction proof overhead.

Compressão ZK

Bulletproofs

A zero-knowledge proof system that produces short, non-interactive proofs without a trusted setup. Bulletproofs are particularly efficient for range proofs — proving a committed value lies within a range without revealing it. Used in confidential transaction systems to prove token amounts are non-negative without disclosing exact values.

Comumente confundido com

Termos próximos em vocabulário, sigla ou vizinhança conceitual.

Essas entradas são fáceis de misturar quando você lê rápido, faz prompting em um LLM ou está entrando em uma nova camada de Solana.

Compressão ZKconcurrent-merkle-tree

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.

AliasCMT
Compressão ZKcanopy-depth

Canopy Depth

The number of top levels of a Concurrent Merkle Tree that are cached on-chain within the CMT account, reducing the Merkle proof size that clients must include in transactions. A canopy depth of D means the top D levels (2^D - 1 nodes) are stored on-chain, so clients only need to supply (tree_depth - D) sibling hashes instead of the full tree_depth. Deeper canopies reduce transaction size and compute costs but increase the CMT account's rent-exempt balance. Choosing optimal canopy depth is a cost trade-off between on-chain storage rent and per-transaction proof overhead.

Compressão ZKmerkle-tree

Merkle Tree

A Merkle tree is a binary hash tree in which every leaf node contains a cryptographic hash of a data block, and every non-leaf (internal) node contains the hash of its two children, such that the single root hash cryptographically commits to the entire dataset and any modification to any leaf produces a detectably different root. In Solana, Merkle trees underpin state compression: the SPL Account Compression program maintains Concurrent Merkle Trees on-chain with only the root hash persisted in account storage, while all leaf data is derivable from transaction logs. The Poseidon hash function is preferred over SHA-256 for ZK-friendly Merkle trees because it is algebraically efficient inside arithmetic circuits used for zero-knowledge proof generation.

Termos relacionados

Siga os conceitos que realmente dão contexto a este termo.

Entradas de glossário só ficam úteis quando estão conectadas. Esses links são o caminho mais curto para ideias adjacentes.

Compressão ZKconcurrent-merkle-tree

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.

Compressão ZKproof-path

Proof Path

A proof path is the ordered sequence of sibling node hashes that constitute a Merkle proof, tracing a route from a specific leaf node up to the tree root by providing the hash of each sibling at every level of the tree. In Solana's compressed account and compressed NFT transactions, the proof path is passed as a list of additional accounts (each account holding a 32-byte hash) in the instruction's account metas, since proof nodes exceed what can fit in instruction data alone for deep trees. The length of the proof path equals tree_depth minus canopy_depth, so indexers like Photon pre-compute and serve proof paths to clients, which can then submit them directly to on-chain programs for verification.

Mais na categoria

Permaneça na mesma camada e continue construindo contexto.

Essas entradas vivem ao lado do termo atual e ajudam a página a parecer parte de um grafo maior, não um beco sem saída.

Compressão ZK

State Compression

State Compression is Solana's technique for storing the cryptographic fingerprint (root hash) of a Merkle tree on-chain while keeping the actual leaf data off-chain in the Solana ledger's account data logs, reducing the cost of storing large datasets by orders of magnitude. A compressed NFT collection of 1 million items costs roughly 50 SOL to mint versus ~12,000 SOL with standard SPL accounts, because only a single Concurrent Merkle Tree account occupies on-chain storage. Any data change requires updating the root hash and supplying a Merkle proof to the on-chain program, which verifies inclusion without reading the full dataset.

Compressão ZK

ZK Compression

ZK Compression, pioneered by Light Protocol, extends Solana's state compression model beyond NFTs to general-purpose compressed accounts by using zero-knowledge proofs (specifically Groth16 SNARKs verified via the alt_bn128 syscall) to prove the validity of state transitions without storing full account state on-chain. Compressed accounts live in on-chain Merkle trees but their data is reconstructed from the Solana ledger by indexers like Photon, enabling developers to build applications that use thousands of accounts at a fraction of the normal rent cost — often 1,000x to 5,000x cheaper than regular accounts. The protocol introduces compressed tokens, compressed PDAs, and a system of nullifiers to prevent double-spends while maintaining Solana's throughput.

Compressão ZK

Compressed Account

A compressed account is a Solana account whose state is stored as a leaf in an on-chain Concurrent Merkle Tree rather than as a dedicated on-chain account, making it 100–1,000x cheaper to create and maintain because no rent-exempt lamport balance is required per account. Compressed accounts are identified by a hash of their data and position in the tree; to interact with one, a client must supply a Merkle proof (or rely on the canopy) showing the leaf is part of the current tree root, which the on-chain program verifies before processing the state change. Light Protocol's compressed account model supports arbitrary data, discriminators, and owner programs, making it a general-purpose replacement for expensive on-chain accounts in high-volume use cases.

Compressão ZK

Concurrent Merkle Tree

A Concurrent Merkle Tree (CMT) is a specialized on-chain Solana data structure that allows multiple state updates to the same Merkle tree within a single block without conflicting, by recording a changelog buffer of recent root transitions that validators use to reconcile parallel proof submissions. A CMT is parameterized by its maximum depth (max_depth, determining tree capacity of 2^max_depth leaves), max_buffer_size (number of concurrent changes the changelog can track, directly controlling how many operations per slot the tree can safely absorb), and an optional canopy_depth. The SPL Account Compression program manages CMTs, and they are the foundational storage primitive for both Metaplex compressed NFTs and Light Protocol compressed accounts.