An arithmetic constraint format used to represent computations as systems of equations for zero-knowledge proof generation. Programs are compiled into R1CS constraints of the form A * B = C, where A, B, C are linear combinations of variables. Groth16 and other SNARKs use R1CS as their computation representation layer.
Empieza por la explicación más corta y útil antes de profundizar.
An arithmetic constraint format used to represent computations as systems of equations for zero-knowledge proof generation. Programs are compiled into R1CS constraints of the form A * B = C, where A, B, C are linear combinations of variables. Groth16 and other SNARKs use R1CS as their computation representation layer.
Usa primero la analogía corta para razonar mejor sobre el término cuando aparezca en código, docs o prompts.
Piensa en esto como un bloque de construcción que conecta una definición aislada con el sistema mayor donde vive.
Ubica el término dentro de la capa de Solana en la que vive para razonar mejor sobre él.
Estado comprimido, pruebas y patrones de almacenamiento orientados a escala.
Convierte el término de vocabulario en algo operacional para producto e ingeniería.
Este término desbloquea conceptos adyacentes rápido, así que funciona mejor cuando lo tratas como un punto de conexión y no como una definición aislada.
Usa este bloque compacto cuando quieras dar contexto sólido a un agente o asistente sin volcar toda la página.
R1CS (Rank-1 Constraint System) (r1cs) Categoría: Compresión ZK Definición: An arithmetic constraint format used to represent computations as systems of equations for zero-knowledge proof generation. Programs are compiled into R1CS constraints of the form A * B = C, where A, B, C are linear combinations of variables. Groth16 and other SNARKs use R1CS as their computation representation layer. Aliases: Rank-1 Constraint System Relacionados: Groth16, SNARK (Succinct Non-interactive Argument of Knowledge), Arithmetic Circuit
Usa contexto del glosario, relaciones entre términos, modelos mentales y builder paths para recibir respuestas estructuradas en vez de output genérico.
Opcional: pega código Anchor, Solana o Rust para que el Copilot mapee primitivas de vuelta al glosario.
El Copilot responderá usando el término actual, conceptos relacionados, modelos mentales y el grafo alrededor del glosario.
Estas ramas muestran qué conceptos toca este término directamente y qué existe una capa más allá de ellos.
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.
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.
A directed acyclic graph of addition and multiplication gates representing a computation over a finite field. Used as the intermediate representation for compiling programs into zero-knowledge proofs. The circuit maps inputs to outputs through a series of field operations, with circuit size (number of gates) determining proof generation cost.
Estos son los siguientes conceptos que vale la pena abrir si quieres que este término tenga más sentido dentro de un workflow real de Solana.
Las entradas del glosario se vuelven útiles cuando están conectadas. Estos enlaces son el camino más corto hacia ideas adyacentes.
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.
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.
A directed acyclic graph of addition and multiplication gates representing a computation over a finite field. Used as the intermediate representation for compiling programs into zero-knowledge proofs. The circuit maps inputs to outputs through a series of field operations, with circuit size (number of gates) determining proof generation cost.
Estas entradas viven junto al término actual y ayudan a que la página se sienta parte de un grafo de conocimiento más amplio en lugar de un callejón sin salida.
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.