Skip to main content

Glossary

A B C D E F I J K L M N O P Q R S T U V 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

best tip

The blockchain's latest block with the highest chain strength known to the mina daemon.

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 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 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.

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.

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

An 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 pub-sub model.

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 and updated with the Mina zkApp CLI, a deploy alias in your project config.json file contains the details to manage deployments.

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

epoch

A unit of time equal to 7140 slots at Mainnet. An epoch is divided into slots of 3minutes 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

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.

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.

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

Kademlia

A distributed hash table (DHT) for decentralized peer-to-peer networks. Mina uses Kademlia for peer discovery so that nodes can find neighbor nodes to share information about the network state.

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.

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.

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

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 provides things like message broadcast and file sharing.

M

Mina

The underlying protocol and the network infrastructure that the system depends on.

MINA

The unit of the cryptocurrency that is exchanged by participating nodes on the Mina network.

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 zkApp CLI

A command line tool that zkApp developers use to scaffold and deploy smart contracts. Install the Mina zkApp CLI.

N

node

A machine running the Mina daemon.

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.

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

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

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.

PLONK

Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge (PLONK) is general-purpose zero knowledge proof scheme.

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.

precomputed block

Precomputed blocks are blocks logged by mina to disk, log file, or to cloud storage.

private key

A component of public key cryptography, private keys are held private 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.

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 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.

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.

publish-subscribe (pub-sub)

A messaging pattern where message senders broadcast messages, and any listeners that have previously subscribed to that sender's messages are notified. 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)] (https://en.wikipedia.org/wiki/Remote_procedure_call) 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.

signature

Short for digital signature, a way to establish authenticity or ownership of digitally signed messages.

slot

A unit of time. As of Mainnet launch, a slot in Mina is 3minutes long. An epoch is divided into slots. Block producers can win the chance to produce a block during a slot.

smart contract

A tamper-proof program that runs on a blockchain network when certain predefined conditions are satisfied. On Mina, smart contracts are written with SnarkyJS.

SNARK

An acronym for succinct non-interactive argument of knowledge. See zk-SNARK.

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

A node on the network that is participating in transaction SNARK generation (the proof). The SNARK worker is incentivized with MINA as compensation to help compress transactions.

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.

SnarkyJS

A TypeScript library for zk-SNARKs and zkApps. Use SnarkyJS to write zk smart contracts based on zero knowledge proofs for the Mina Protocol.

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 winning a slot 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.

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 perform 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

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.

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 to 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. SnarkyJS 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.

zkApp

Zero knowledge apps (zkApps) are Mina Protocol's smart contracts powered by zero-knowledge proofs, specifically using zk-SNARKs. The easiest way to write zk programs is using SnarkyJS.

zk-SNARK

A type of 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 that allow for any node to quickly verify the state of the network.

Back to top