Technique of combining multiple zero-knowledge proofs into a single, compact proof that can be verified more efficiently than verifying each proof individually. Reduces on-chain verification costs by batching proofs. Used in ZK compression systems to batch-verify multiple state transitions in a single verification step on Solana.
Comece pela explicação mais curta e útil antes de aprofundar.
Technique of combining multiple zero-knowledge proofs into a single, compact proof that can be verified more efficiently than verifying each proof individually. Reduces on-chain verification costs by batching proofs. Used in ZK compression systems to batch-verify multiple state transitions in a single verification step on Solana.
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.
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.
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.
Use este bloco compacto quando quiser dar contexto aterrado para um agente ou assistente sem despejar a página inteira.
Proof Aggregation (proof-aggregation) Categoria: Compressão ZK Definição: Technique of combining multiple zero-knowledge proofs into a single, compact proof that can be verified more efficiently than verifying each proof individually. Reduces on-chain verification costs by batching proofs. Used in ZK compression systems to batch-verify multiple state transitions in a single verification step on Solana. Relacionados: Zero-Knowledge Proofs (ZKP), ZK Compression, Validity Proof
Use contexto do glossário, relações entre termos, modelos mentais e builder paths para receber respostas estruturadas em vez de output genérico.
Opcional: cole código Anchor, Solana ou Rust para o Copilot mapear primitivas de volta para termos do glossário.
O Copilot vai responder usando o termo atual, conceitos relacionados, modelos mentais e o grafo ao redor do glossário.
Esses ramos mostram quais conceitos esse termo toca diretamente e o que existe uma camada além deles.
A zero-knowledge proof is a cryptographic protocol by which a prover convinces a verifier that a statement is true — for example, that a state transition is valid — without revealing any information beyond the truth of the statement itself, satisfying the properties of completeness, soundness, and zero-knowledge. In Solana's ecosystem, ZKPs are used by ZK Compression (via Groth16 SNARKs) to prove correct state transitions for compressed accounts without storing full account state on-chain, and by the Token-2022 Confidential Transfers extension (via ElGamal encryption and range proofs) to prove token balances are non-negative without revealing the actual amounts. Solana's BPF VM exposes the alt_bn128 elliptic curve syscall to make on-chain Groth16 proof verification computationally feasible within the 1.4M compute unit budget.
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.
In the context of ZK Compression on Solana, a validity proof is a Groth16 zk-SNARK proof that cryptographically attests to the correctness of one or more compressed account state transitions — specifically, that the consumed accounts exist as leaves in the current Merkle tree root, that the nullifiers are fresh (not previously spent), and that the new output account hashes correctly represent the post-transition state — all without the verifier needing to inspect the full account data. Validity proofs are generated off-chain by Light Protocol's prover service and submitted alongside compressed account instructions in Solana transactions, where the Light System Program verifies the proof on-chain using the alt_bn128 syscall before applying the state change. This model means Solana validators do not re-execute compressed account logic; they only verify the succinct proof, enabling high-throughput compressed state updates at minimal on-chain cost.
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.
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.
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.
A Merkle proof is the minimal set of sibling node hashes (the proof path) along the branch from a specific leaf to the tree root, allowing anyone to independently verify that a given leaf is part of a Merkle tree by recomputing the root from the leaf hash and the sibling hashes without needing any other tree data. In Solana's state compression, every compressed account or compressed NFT interaction requires the caller to supply a valid Merkle proof; the on-chain program hashes the proof against the current root stored in the Concurrent Merkle Tree account to confirm inclusion before executing the state change. Proof size scales linearly with tree depth (e.g., a depth-20 tree requires up to 20 sibling hashes, each 32 bytes), so the canopy is used to pre-store upper-level nodes on-chain to reduce the proof data that must be passed in transactions.
A zero-knowledge proof demonstrating that a committed value falls within a specified range (e.g., 0 to 2^64) without revealing the value itself. Essential for confidential transactions to prove that transfer amounts are non-negative and don't exceed the sender's balance, preventing hidden inflation or underflow attacks.
Entradas de glossário só ficam úteis quando estão conectadas. Esses links são o caminho mais curto para ideias adjacentes.
A zero-knowledge proof is a cryptographic protocol by which a prover convinces a verifier that a statement is true — for example, that a state transition is valid — without revealing any information beyond the truth of the statement itself, satisfying the properties of completeness, soundness, and zero-knowledge. In Solana's ecosystem, ZKPs are used by ZK Compression (via Groth16 SNARKs) to prove correct state transitions for compressed accounts without storing full account state on-chain, and by the Token-2022 Confidential Transfers extension (via ElGamal encryption and range proofs) to prove token balances are non-negative without revealing the actual amounts. Solana's BPF VM exposes the alt_bn128 elliptic curve syscall to make on-chain Groth16 proof verification computationally feasible within the 1.4M compute unit budget.
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.
In the context of ZK Compression on Solana, a validity proof is a Groth16 zk-SNARK proof that cryptographically attests to the correctness of one or more compressed account state transitions — specifically, that the consumed accounts exist as leaves in the current Merkle tree root, that the nullifiers are fresh (not previously spent), and that the new output account hashes correctly represent the post-transition state — all without the verifier needing to inspect the full account data. Validity proofs are generated off-chain by Light Protocol's prover service and submitted alongside compressed account instructions in Solana transactions, where the Light System Program verifies the proof on-chain using the alt_bn128 syscall before applying the state change. This model means Solana validators do not re-execute compressed account logic; they only verify the succinct proof, enabling high-throughput compressed state updates at minimal on-chain cost.
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.
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.
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.
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.
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.