Glossary OS

Leitura rápida

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

Groth16 is a highly efficient zk-SNARK proving system introduced by Jens Groth in 2016 that produces constant-size proofs (128 bytes: two G1 points and one G2 point on a pairing-friendly elliptic curve) with constant-time verification regardless of circuit complexity, making it the preferred proof system for on-chain verification where calldata and compute costs are constrained. Light Protocol uses Groth16 proofs over the BN254 curve (known as alt_bn128 in Ethereum tooling) to verify compressed account state transitions on Solana, leveraging the native alt_bn128 pairing and point-addition syscalls added to the SVM to keep verification within the per-transaction compute unit limit. The trade-off is that Groth16 requires a trusted setup ceremony per circuit, producing a structured reference string (SRS) whose security relies on participants honestly discarding their toxic waste.

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

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

Groth16 (groth16)
Categoria: Compressão ZK
Definição: Groth16 is a highly efficient zk-SNARK proving system introduced by Jens Groth in 2016 that produces constant-size proofs (128 bytes: two G1 points and one G2 point on a pairing-friendly elliptic curve) with constant-time verification regardless of circuit complexity, making it the preferred proof system for on-chain verification where calldata and compute costs are constrained. Light Protocol uses Groth16 proofs over the BN254 curve (known as alt_bn128 in Ethereum tooling) to verify compressed account state transitions on Solana, leveraging the native alt_bn128 pairing and point-addition syscalls added to the SVM to keep verification within the per-transaction compute unit limit. The trade-off is that Groth16 requires a trusted setup ceremony per circuit, producing a structured reference string (SRS) whose security relies on participants honestly discarding their toxic waste.
Relacionados: Zero-Knowledge Proofs (ZKP), SNARK (Succinct Non-interactive Argument of Knowledge)

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.

Abrir workspace completa do Copilot

Pergunta

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

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

Zero-Knowledge Proofs (ZKP)

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.

PLONK

Abrir termo

Ramo

SNARK (Succinct Non-interactive Argument of Knowledge)

A SNARK is a class of zero-knowledge proof system characterized by succinctness (proofs are short — typically hundreds of bytes — regardless of the computation's complexity), non-interactivity (the prover sends a single message without back-and-forth with the verifier), and the argument-of-knowledge property (a prover who produces a valid proof must know the witness, i.e., the secret inputs to the computation). zk-SNARKs such as Groth16 and PLONK are the cryptographic core of ZK Compression on Solana, enabling off-chain provers to compress complex state transition validity into a proof that a Solana validator can verify on-chain cheaply using the alt_bn128 syscall over the BN254 elliptic curve. Most current Solana zk-SNARK deployments rely on trusted setups, though newer transparent variants like STARKs eliminate this requirement at the cost of larger proof sizes.

Abrir termo

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

Zero-Knowledge Proofs (ZKP)

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.

Abrir termo

Compressão ZK

SNARK (Succinct Non-interactive Argument of Knowledge)

A SNARK is a class of zero-knowledge proof system characterized by succinctness (proofs are short — typically hundreds of bytes — regardless of the computation's complexity), non-interactivity (the prover sends a single message without back-and-forth with the verifier), and the argument-of-knowledge property (a prover who produces a valid proof must know the witness, i.e., the secret inputs to the computation). zk-SNARKs such as Groth16 and PLONK are the cryptographic core of ZK Compression on Solana, enabling off-chain provers to compress complex state transition validity into a proof that a Solana validator can verify on-chain cheaply using the alt_bn128 syscall over the BN254 elliptic curve. Most current Solana zk-SNARK deployments rely on trusted setups, though newer transparent variants like STARKs eliminate this requirement at the cost of larger proof sizes.

Abrir termo

Compressão ZK

Light Protocol

Light Protocol is the open-source infrastructure layer that implements ZK Compression on Solana, consisting of a set of on-chain programs (the Light System Program, Compressed Token Program, and Account Compression Program), an off-chain prover network that generates Groth16 proofs for state transitions, the Photon indexer that reconstructs compressed account state from Solana ledger data, and the Forester service that manages Merkle tree maintenance tasks like nullifier queue processing. Light Protocol enables developers to build general-purpose compressed accounts, compressed SPL tokens, and compressed PDAs that are 100–1,000x cheaper than their standard counterparts while inheriting Solana's full security, atomicity, and composability guarantees. The protocol is permissionlessly deployable and integrates with existing Solana tooling via a drop-in SDK that mirrors familiar account and token patterns.

Abrir termo

Compressão ZK

Forester

Forester is the permissionless keeper service in Light Protocol's architecture responsible for performing routine Merkle tree maintenance operations that must be triggered by an external party rather than automatically on-chain, including nullifier queue processing (finalizing spent compressed account hashes to prevent double-spends), address queue processing (registering new compressed account addresses), and rolling epoch-based tree updates. Without an active Forester, nullifier queues can fill up and block new state transitions in a compressed tree, so Light Protocol incentivizes Forester operators through protocol fees collected during these maintenance operations. Forester nodes are run permissionlessly by anyone against a Solana RPC and monitor on-chain queue accounts, submitting crank transactions when queues require processing.

Abrir termo

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 ZKzk-proofs

Zero-Knowledge Proofs (ZKP)

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.

Abrir termo

Compressão ZKsnark

SNARK (Succinct Non-interactive Argument of Knowledge)

A SNARK is a class of zero-knowledge proof system characterized by succinctness (proofs are short — typically hundreds of bytes — regardless of the computation's complexity), non-interactivity (the prover sends a single message without back-and-forth with the verifier), and the argument-of-knowledge property (a prover who produces a valid proof must know the witness, i.e., the secret inputs to the computation). zk-SNARKs such as Groth16 and PLONK are the cryptographic core of ZK Compression on Solana, enabling off-chain provers to compress complex state transition validity into a proof that a Solana validator can verify on-chain cheaply using the alt_bn128 syscall over the BN254 elliptic curve. Most current Solana zk-SNARK deployments rely on trusted setups, though newer transparent variants like STARKs eliminate this requirement at the cost of larger proof sizes.

Abrir termo

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.

Abrir termo

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.

Abrir termo

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.

Abrir termo

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.

Abrir termo