Glossary
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Are you looking for a zero knowledge or Mina term that isn't here yet? To let us know, please create an issue or click EDIT THIS PAGE to submit a PR.
A
account
Mina uses accounts to track each public key's state. This is distinct from Bitcoin's UTXO model of maintaining ledger state.
archive node
A Mina node that stores the historical chain data to a persistent data source so it can later be retrieved. A zkApp can retrieve events and actions from one or more Mina archive nodes.
B
Base58
A group of encoding/decoding schemes used to switch data between binary format (hexadecimal) and alphanumeric text format (ASCII). The Base58 alphabet includes numbers (1 to 9) and English letters, except O (uppercase o), I (uppercase i), and l (lowercase L). These letters are omitted to avoid confusion.
Base64
A binary-to-text encoding scheme that represents binary data in a human-readable ASCII string format string. For example, the zero knowledge proof is a Base64 string inside the authorization field of a transaction.
best tip
The blockchain's latest block with the highest chain strength known to the mina daemon.
bitwise operations
Generally available in most programming languages, including TypeScript, bitwise operations manipulate individual bits within a binary representation of a number. o1js provides versions of bitwise operations that operate on Field elements and result in the necessary circuit constraints to generate a zero knowledge proof of the computation.
block
A set of transactions and consensus information that extend the state of the network. A block in Mina includes a proof that the current state of the network is fully valid. See also extensional blocks and precomputed blocks. See What's in a Block?
blockchain
The data structure that is used in a cryptocurrency to maintain a shared state of all accounts in the network.
block confirmations
The number of blocks added after the reference block. As the number of confirmations increases, the likelihood of a reorganization decreases, thereby increasing the likelihood of all transactions in the reference block being confirmed.
block explorer
A web-based tool to extract, visualize, and review blockchain network metrics, including transaction histories, wallet balances, and details about individual blocks and transactions. Block explorers for Mina include:
block fill rate
The proportion of slots that should contain a block. Some slots are intentionally empty to ensure the network can catch up in case of delay of messages.
block header
The portion of a block that contains information about the block itself (block metadata), typically includes a timestamp, a hash representation of the block data, the hash of the previous block's header, and a cryptographic nonce (if needed).
block producer
A node that participates in a process to determine what blocks it is allowed to produce and then produces blocks containing transactions that can be broadcast to the network. People who run block producer nodes are also called block producers.
bootstrap
Part of the syncing process of a node, bootstrapping gets the current root of the transition frontier from peers. Additional transitions obtained during the catchup process are applied from this initial root state.
breadcrumb
A node in the transition frontier that contains the external transition, staged ledger, and pending coinbases and is generated by applying the transition to the prior state.
C
catch up
The final stage of the syncing process where the node attempts to catch up to the current best tip by determining and then downloading all transitions between the transition frontier root and the current best tip. First, a node requests the missing transition hashes and a transaction chain proof. This proof proves the path provided is valid, for example, that the provided transition hashes lead from the root to the best tip. After the node has all transition hashes, it requests the full external transition for each transition hash from peers.
With each external transition, the node builds up its transition frontier by applying each to the prior state to construct a breadcrumb. When the catch up stage is complete, the node's local best tip is the same as the network's best tip, and breadcrumbs have been constructed for all transitions from the transition frontier root (best tip - k) to the current tip, and each has been validated. At this point, the node is synced.
A catch up can be triggered at any time if the node sees a disjoint transition in the same path that indicates there are missing transitions.
chain strength
Full history is not available in Mina, so a newly connected node to the network cannot sync from genesis by applying all prior transitions. To allow a node to determine the strongest chain, a minimum chain density is stored for a sliding window of time. As a result, honest nodes can choose the blockchain with the higher minimum density or chain strength.
cold wallet
A cold wallet is not, and never has been, available on the internet. Cold storage is safer for wallets associated with meaningful stake.
compressing
Generating a SNARK for a computation output can be thought of as compressing that output, as the proofs are fixed size. For example, Mina maintains a succinct blockchain by compressing all the historical data in a blockchain into a zk-SNARK. However, this is computationally different from lossy compression. The term compress is used to more figuratively describe the process of reducing the size of required data.
consensus
A process through which all the peers of a blockchain network reach a common agreement about the present state of the distributed ledger. A consensus algorithm or set of rules that Mina nodes all agree upon when deciding to update the state of the network. Rules can include what data a new block can contain and how nodes are selected and rewarded for adding a block. Mina implements the Ouroboros Samisika consensus mechanism.
consensus node
A participant in the Mina network that performs the consensus function, for example, a block producer.
cryptocurrency
A digital asset or currency that uses cryptographic primitives to secure financial transactions and to verify ownership by using public/private key pairs.
D
daemon
The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subcribe model.
DAO
A decentralized autonomous organization (DAO) operates based on rules that are encoded on a blockchain and executed through smart contracts. DAOs are an organizational structure built with blockchain technology.
Dapp
A decentralized application (Dapp) runs on a blockchain or decentralized network and offers benefits such as transparency, security, and censorship resistance. In the Mina ecosystem, Dapps are known as zkApps.
delegating
Because staking MINA requires nodes to be online, some nodes delegate their MINA to another node that runs a staking service. This process is called delegating a stake. The service provider or staking pool operator can charge a fee that is deducted any time the delegator gets selected to be a block producer.
deploy alias
Created with the zkApp CLI, a deploy alias in your project config.json file contains the details to manage deployments.
Devnet
Dedicated for developers building on top of the Mina protocol, Devnet is designed for testing and experimentation so you can test tooling and integrations before going live on Mainnet. See Connect to Devnet.
distributed ledger technology (DLT)
A digital system for recording the transaction of assets in which the transactions and their details are recorded in multiple places at the same time. In contrast to traditional databases, distributed ledgers have no central data store or administration functionality.
E
ECDSA
Elliptic Curve Digital Signature Algorithm (ECDSA) a cryptographic algorithm used to sign and verify messages. It is used in many blockchains, including Ethereum, to sign transactions.
elliptic curves
Equations with a specific template, including: y^2 = x^3 + ax^ + b: secp256k1.
elliptic-curve cryptography (ECC)
An approach to public key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC is the basis of how Ethereum and other cryptocurrencies use private keys and digital signatures.
epoch
A unit of time equal to 7140 slots at Mainnet. An epoch is divided into slots of 90 seconds each.
extensional blocks
Blocks extracted from the mina-archive database contain only the information required to restore data to the archive node and are more lightweight than precomputed blocks.
external port
The port that the Mina daemon uses to connect to other nodes on the network. When starting the daemon, set using -external-port.
external transition
Also referred to as a block, an external transition is generated externally, for example, by another block producer, and gossiped to a node.
F
fee payer account
A developer account that is funded and can always pay fees immediately. When you configure a zkApp, you can choose to use a stored account or create a new fee payer account.
field element
The basic unit of data in zero knowledge proof programming. Each field element can store a number up to almost 256 bits in size. You can think of a field element as a uint256 in Solidity. For the cryptography inclined, the exact max value that a field can store is 28,948,022,309,329,048,855,892,746,252,171,976,963,363,056,481,941,560,715,954,676,764,349,967,630,336.
finality
A consensus constant k is the point at which chain reorganizations are no longer possible. After a block has k block confirmations as defined by the consensus constants, it is considered final.
foreign field
A finite field different from the native field of the proof system. Foreign Field Arithmetic lets you perform algorithms that connect your zkApp with the outside world of cryptography.
full node
A Mina node that is able to verify the state of the network trustlessly. In Mina, every node is a full node since all nodes can receive and verify zk-SNARKs.
G
gadgets
Small, reusable, low-level building blocks that simplify the process of creating new cryptographic primitives. Most gadgets build upon custom gates and act as low-level accelerators in the proof system.
H
hash
A mathematical cryptographic function that converts an input of arbitrary length into an encrypted output of a fixed length. Hashing provides security through encryption and is an efficient store of data because the hash is of a fixed size.
hot wallet
A hot wallet has a private key that is available on a machine that is connected to the internet. To mitigate risk, avoid having hot wallets with substantial stake.
I
internal transition
A transition that is produced locally, for example, by a block producer. The generated transition is applied locally and added to the transition frontier before being broadcast to peers.
K
Keccak
Keccak (SHA-3) is a flexible cryptographic hash function that provides more security than traditional SHA hash algorithms.
key pair
A combination of a private key and public key. Key pairs can be generated by using a running daemon or using a dedicated keygen tool, see Generating a Key Pair. In Mina, public keys start with B62 and private keys start with EK for easy differentiability.
Kimchi
The proof system for Mina, Kimchi is the main machinery that generates the recursive proofs that keep the Mina blockchain small (about 22 KB). Kimchi is a zero knowledge proof system that's a variant of PLONK and features a polynomial commitment scheme that supports verifiable computation using traditional Turing machine-based instruction sets.
L
layer 1 (L1)
The fundamental, base-level chain in a network. An L1 blockchain provides the essential services to a network, like recording transactions on the public ledger and ensuring adequate security. Mina is a layer 1 blockchain.
layer 2 (L2)
An off-chain network, system, or technology built on top of a layer 1 blockchain that helps extend the capabilities of the underlying base layer network.
ledger
A cryptocurrency public record-keeping system. Mina has three types of ledgers: staged ledger, staking ledger, and SNARKed ledger.
libp2p
Mina uses this peer-to-peer networking library to provide things like message broadcast and file sharing.
Lightnet
A lightweight Mina network in a single Docker container. Lightnet is a resource-efficient solution with fast startup and syncing times that lets you test your zkApp locally on an accurate representation of Mina blockchain before you test with a live network.
lightweight Mina Explorer
Provided in Lightnet, a lightweight Mina Explorer lets you monitor transactions on your local network. See Testing zkApps with Lightnet.
M
major upgrade
Changes to the network that make the old chain incompatible with the new chain. A major upgrade to the Mina network requires all nodes or users to upgrade to the latest version of the protocol software.
Mainnet
The live version of the Mina blockchain network that is fully operational. On the Mina Mainnet public blockchain, real-world transactions are performed. See Connect to the Mina Network. A Mainnet is different from a Testnet and Devnet which are used for development and testing.
MINA
The unit of the cryptocurrency that is exchanged by participating nodes on the Mina network. MINA is the exclusive currency of the snarketplace.
Mina
The underlying protocol and the network infrastructure that the system depends on.
Mina CLI
The primary way for users to interact with the Mina network. The Mina CLI command line tool provides standard client functionality to create accounts, send transactions, and participate in consensus and advanced client and daemon commands for power users.
The Mina CLI is installed when you install Mina.
Mina nodes
Mina nodes fulfill different roles within the network, including block producers and SNARK coordinators.
N
node
A machine running the Mina daemon.
node operators
People who run Mina nodes. Node operators participate in consensus to create new blocks and help compress data by generating zk-SNARKs.
non-consensus node
A full node in the Mina protocol that does not participate in consensus but can still fully verify the zero knowledge proof to trustlessly validate the state of the chain. The size of Mina as 22 KB is in reference to non-consensus nodes.
non-upgradeable
If the verification key cannot be changed, a zkApp smart contract is considered non-upgradeable. You can make a smart contract upgradeable or not upgradeable using permissions.
nonce
An incrementing number attached to a transaction used to prevent a replay of a transaction on the network. Transactions are always included in blocks in the sequential order of the nonce.
O
o1js
A TypeScript library for zk-SNARKs and zkApps. Use o1js to write zk smart contracts based on zero knowledge proofs for the Mina Protocol.
off-chain
A transfer of value or data, including transactions, that occurs outside a given blockchain network. These transfers do not need blockchain network confirmation, which speeds up the transaction process and reduces lag time. zkApps use an off-chain execution and mostly off-chain state model that allows for private computation and state that can be either private or public.
off-chain state
State stored anywhere other than the Mina blockchain.
on-chain
A transfer of value or data, including transactions, that exist on and have been verified to a blockchain network. All relevant information is timestamped and stored on the public ledger. On-chain transactions are recorded on the blockchain and need network confirmation before they are completed.
on-chain state
State that lives on the Mina blockchain. Each zkApp account provides 32 fields of 32 bytes each of arbitrary storage for the on-chain state.
oracle
Specialized software or services that act as intermediaries between blockchain smart contracts and external data sources. Oracles connect zkApp smart contracts with the outside world to get data on-chain.
Ouroboros Samisika
Mina builds on this provably secure proof of stake (PoS) protocol that combines the best features of each iteration of Ouroboros to deliver a PoS consensus mechanism that can resolve long-range forks without requiring history or risking centralization by relying on trusted third parties to provide fork information.
P
pasta curves
A collective term for the Pallas and Vesta elliptic curves that are used by the Mina Protocol to generate proofs. See Pasta Curves in the Mina book.
peer-to-peer networks
Networking systems that rely on peer nodes to distribute information amongst each other, are often distributed, and do not rely on any centralized resource broker.
Pickles
Mina's inductive zk-SNARK composition system. See Pickles.
Pickles SNARK
A proof system and associated toolkit that is the first deployed SNARK capable of recursive composition with no trusted setup. Pickles serves as the basis for developers to build private, scalable smart contracts on Mina. Meet Pickles SNARK: Enabling Smart Contracts on Mina Protocol.
PLONK
Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge (PLONK) is a general-purpose zero knowledge proof scheme.
polynomial commitment
A commitment scheme that allows a committer to commit to a polynomial with a short string that can be used by a verifier to confirm claimed evaluations of the committed polynomial.
Poseidon
A family of hash functions that can efficiently run in a zk circuit. Poseidon operates over the native Pallas base field and uses parameters generated specifically for Mina, which makes Poseidon the most efficient hash function available in o1js. See Poseidon: ZK-friendly Hashing. Poseidon is a sponge construction based on the Hades permutation, with a state composed of field elements and a permutation based on field element operation (addition and exponentiation).
precomputed blocks
Precomputed blocks are blocks logged by mina to disk, log file, or to cloud storage.
preconditions
Conditions that must be true for the account update to be applied. Corresponds to assertions in an o1js method.
private key
A component of public key cryptography, private keys are held privately, while public keys can be issued publicly. Only the holder of the public key's corresponding private key can attest to ownership of the public key. This allows for signing transactions to prove that you are the honest holder of any funds associated with any given public key. In Mina, private keys start with EK for easy differentiability from public keys.
protocol state
The state of the network that comprises the previous protocol state hash to link blocks together and a body that contains the genesis state hash, blockchain state, consensus state, and consensus constants.
protocol state hash
The hash of hashes of the previous state and protocol state body. Acts as a unique identifier for a block.
proof of liabilities (PoL)
A cryptographic primitive to prove the size of funds a bank, or centralized exchange (CEX), owes to its customers in a decentralized manner and can be used for solvency audits with better privacy guarantees.
proof of stake (PoS)
The Mina consensus algorithm that allows nodes to agree on the state of the network. PoS allows nodes to stake MINA on the network to increase their chance of being selected as the next block producer. The winning validators are compensated with a percentage yield of the crypto they have staked as an incentive for engaging in this process. See Proof-of-Work vs Proof-of-Stake.
proof of work (PoW)
The original consensus process used by Bitcoin, the first cryptocurrency. PoW achieves the decentralized consensus needed to add new blocks to a blockchain by using machines to compete against one another by guessing the answer to math problems that have no feasible faster solution. Computational power is a requirement for the PoW protocol success and assumes that those contributing more resources (energy, supercomputers, and infrastructure) to a problem are less likely to want to destroy the protocol. As an incentive to participate in this consensus process, miners are rewarded with tokens.
prover function
The function that generates a zero knowledge proof from the smart contract logic.
public key
A component of public key cryptography, public keys can be widely shared with the world and can be thought of as addresses or identifiers for the person who holds the corresponding private key. In Mina, public keys start with B62 for easy differentiability from private keys.
publish-subscribe (pub-sub)
A messaging pattern where message senders broadcast messages and notifies any listeners that have previously subscribed to that sender's messages. Mina utilizes pub-sub as a way to notify clients when a new block has been added to the chain. This event can be heard by all listeners, so each listener does not need to independently poll for new data.
R
recursion
The layer 1 architecture of Mina Protocol is based on recursive composition, which means that each block in the blockchain is a tiny snapshot of the entire state of the network. This approach enables Mina to maintain a constant blockchain size of only 22KB regardless of the number of transactions processed. With recursion, you can realize composability between zero knowledge proofs to unlock many powerful technical abilities, such as creating high-throughput applications, creating proofs of large computations, and constructing multi-party proofs.
reorganization
When a competing fork of the blockchain increases in length relative to the main branch, the blockchain undergoes a reorganization to reflect the stronger fork as the main branch. After a reorganization, the transactions on the dropped branch are no longer guaranteed inclusion into the blockchain and must be added to new blocks on the longest branch.
root of transition frontier
The root of the transition frontier is the block k blocks from the best tip. The root is obtained from peers during bootstrap. After a new best tip is seen, the root is moved, so only k blocks are persisted. The root is the point where the block has been finalized due to consensus.
remote procedure call (RPC)
An RPC is used to communicate between nodes on the network and to interact with the running daemon.
S
scan state
A data structure that allows decoupling the production of transaction SNARKs from block producers to SNARK workers. See Scan State.
secp256k1
The elliptic curve using this equation y²=x³+7, a=0 b=7, constructed in a special non-random way to allow for especially efficient computation. secp256k1 can have a key size of up to 256 bits. All points on this curve are valid public keys.
seed nodes
A Mina node that keeps a record of nodes in the network and enables nodes that are joining the network to connect to peer nodes.
SHA-2
Secure Hash Algorithm 2 (SHA-2) is a family of two similar hash functions with different block sizes known as SHA-256 and SHA-512 that differ in word size. SHA-256 uses 32-bit words and SHA-512 uses 64-bit words.
SHA-256
SHA-256, a part of the SHA-2 family, is a cryptographic hash function that generates a 256-bit (32-byte) hash output and is widely used for traditional Web2 applications and protocols as well as blockchain technology.
SHA-3
Secure Hash Algorithm 3 (SHA-3) is the latest member of the Secure Hash Algorithm family of standards, released by NIST on August 5, 2015. Keccak was standardized as SHA-3.
signature
Short for digital signature, a way to establish authenticity or ownership of digitally signed messages.
simulated local blockchain
The local testing blockchain you use in the first phase of testing. Using a simulated local blockchain speeds up development and tests the behavior of your smart contract locally. See Testing zkApps Locally and get step-by-steps guidance in Tutorial 1: Hello World.
slot
A unit of time in the Mina network. A slot in Mina is 90 seconds long. An epoch is divided into slots. Block producers can find eligible slots to produce blocks in to earn rewards.
smart contract
A tamper-proof program that runs on a blockchain network when certain predefined conditions are satisfied. On Mina, smart contracts (zkApps) are written with o1js.
SNARK
An acronym for succinct non-interactive argument of knowledge. See zk-SNARK.
SNARK coordinator
A role on a mina node in the Mina network. SNARK coordinators generate proofs of transactions by distributing work to a series of SNARK workers. SNARK coordinators then submit that work to the network, and the proofs are sold to block producers.
SNARK pool
Referred to as the snarketplace, the pool that contains work completed by SNARK workers for required work in the scan state. The SNARK pool contains only the cheapest work offered by SNARK workers for each work bundle. Multiple SNARK workers compete for the same SNARK work, with only the lowest fee for each being included in the SNARK pool to be bought by block producers.
SNARK worker
External processes that connect to a Mina node on the network and create zk-SNARK proofs of transactions to compress the transactions so they can be folded into the tiny blockchain proof. The SNARK worker is incentivized with MINA as compensation to help compress transactions. See What are SNARK Workers and the Snarketplace?.
SNARKed ledger
The ledger that contains only the transactions that have an associated proof. The SNARKed ledger is updated after a proof has been emitted from the scan state.
snarketplace
Similar to a marketplace where people, or nodes, exchange services for a fee. It revolves around a fixed-size buffer like a queue or shelf of work to do. Block producers add work to this shelf in the form of transactions that need to be SNARKed, and then SNARK workers take the work off the shelf and create SNARKs out of them to process the transactions. Block producers purchase SNARK work for the lowest price from the snarketplace. Conversely, the SNARK workers want to maximize their profit while also being able to sell their SNARK work. These two roles act as the two sides of the marketplace and, over time, establish an equilibrium at a market price for SNARK work.
soft fork
An upgrade to the network that is backward-compatible.
staged ledger
The current account state that contains a pending accounts ledger and also a pending queue of un-SNARKed transactions known as the scan state.
staking
Staking MINA allows nodes on the network to increase their chances of being selected as a block producer in accordance with the consensus mechanism.
staking ledger
The ledger used to determine block producers for a slot, as the probability of finding eligible slots to produce blocks in is proportional to the amount of stake.
staking pool
A pool of delegated funds that is run by a staking pool owner. To avoid the requirement of being online, other nodes can choose to delegate funds to a staking pool.
state
The current status or snapshot of all data stored within the blockchain.
syncing
To successfully produce a block that extends the Mina blockchain, a node requires the current state. To achieve this, a node initializes to connect to peers, bootstrap, and then performs a catchup.
The syncing process builds the node's transition frontier by creating breadcrumbs for all transitions between the transition frontier's root to the current best tip. When complete, the node is synced.
T
Testnet
An instance of a blockchain used for testing and experimenting where MINA tokens have no real value. For example, for zkApp Developer Tutorials and other development, you can request tMINA funds from the Testnet Faucet to fund your fee payer account. Mina's public Testnet is feature-complete and is called the Devnet.
time-locked accounts
An account with a non-vested amount of tokens that cannot be moved until a specific condition has been met, like a number of blocks that has been produced. See Time-Locked Accounts.
tMINA
MINA tokens that have no real-world value. You can request tMINA funds from the Testnet Faucet to fund your fee payer account during development.
tokens
A digital asset that typically represents an asset, utility, or value in a particular blockchain ecosystem. The native cryptocurrency of the Mina blockchain is MINA. Tokens can serve a variety of purposes, including accessing platform features (utility tokens), representing ownership of assets (security tokens), or facilitating smart contracts and decentralized applications (Dapps).
transaction pool
An in-memory store of all the transactions that peer has heard on the network. Sometimes referred to as the mempool, each node has a local list of all pending transactions that have been gossiped to the node and validated.
transition
A transition in Mina is synonymous with a block.
transition frontier
A local data store that contains the last k blocks of the network. With a rose tree-type data structure, each node of the tree is a breadcrumb and can have multiple children (forks).
TypeScript
A superset of JavaScript that adds compile-time type safety. o1js is a TypeScript library for zk-SNARKs and zkApps. See the official TypeScript docs.
U
user transaction
A transaction that is issued by a user, like a payment or a delegation change.
V
verification key
A piece of data that is generated by the smart contract build process. When a smart contract is deployed, a transaction that contains the verification key is sent to an address on the Mina blockchain. Sending a verification key to a zkApp account allows Mina to verify zero knowledge proofs that were generated by a smart contract's prover function.
verifier function
The function that verifies a zero knowledge proof using the verification key.
verifiable random function (VRF)
A function that generates an output that can be cryptographically verified as random. Mina uses VRF to select a block producer for a slot, taking as input a random seed that is derived from the previous epoch's VRF outputs, a public key, and the current staking ledger. VRF is deterministic, so the same output is returned regardless of how often it is run.
Z
zero knowledge proof
A proof by which one party (a prover) can prove to another party (a verifier) that they have knowledge of something, without giving away that specific knowledge. Mina uses zero knowledge proofs, specifically zk-SNARKs, to generate a proof attesting to the blockchain's validity and allows any node on the network to verify the validity.
zkApps
Zero knowledge apps (zkApps) are Mina Protocol's smart contracts powered by zero-knowledge proofs, specifically using zk-SNARKs. zkApps provide powerful and unique characteristics such as unlimited off-chain execution, privacy for private data inputs that are never seen by the blockchain, the ability to write smart contracts in TypeScript, and more. The easiest way to write zk programs is using o1js.
zkApp CLI
A command line tool that zkApp developers use to scaffold and deploy smart contracts. Install the zkApp CLI.
zkApp account
A smart contract account. Each zkApp account provides 32 fields of 32 bytes each of arbitrary storage. When a Mina address contains a verification key, it acts as a zkApp account.
zkApp manager account
A specific type of smart contract that manages a particular thing. For example, the zkApp manager account for a token controls all properties of token accounts and determines rules for token minting, burning, and transfer.
zkBridge
Technology that the Mina network uses to connect to other chains.
zk-SNARK
A zero knowledge proof. zk-SNARK is the acronym for zero knowledge succinct non-interactive argument of knowledge. Specific properties of interest in Mina's implementation of SNARKs are succinctness and non-interactivity, which allow for any node to quickly verify the state of the network. SNARK workers create zk-SNARKs for each transaction. zk-SNARKs are used to create recursive zk-SNARKs that prove the correctness of a block, and in turn, these zk-SNARKs are used to create recursive zk-SNARKs that prove the correctness of the network.