Skip to main content

Glossary

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​

Mina nodes are succinct by default, meaning they don't need to maintain historical information about the network, block, or transactions. An archive node stores the historical chain data to a persistent data source so it can later be retrieved.

Best Tip​

The best tip is the blockchain's latest block with the highest chain strength known to the daemon.

Block​

A set of transactions and consensus information that extend the state of the network. Includes a proof that the current state of the network is fully valid.

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.

Bootstrap​

Bootstrapping is 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 breadcrumb is a "node" in the transition frontier. A breadcrumb contains the external transition, staged ledger, and pending coinbases and is generated by applying the transition to the prior state.

Catchup​

Catchup is the final stage of the syncing process. During catchup, the node will attempt to catchup to the current best tip by determining, 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, i.e., that the provided transition hashes lead from the root to the best tip. Once 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 catchup 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.

At any time, a catchup may be triggered if the node sees a disjoint transition in the same path, indicating there are missing transitions.

Chain Strength​

As there is no full history available in Mina, 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 may 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, and the term compress is used to more figuratively describe the process of reducing the size of data required.

Consensus​

An algorithm or set of rules that Mina nodes all agree upon when deciding to update the state of the network. Rules may include what data a new block can contain and how nodes are selected and rewarded for adding a block. Mina implements Ouroboros Samisika as its consensus mechanism.

Consensus Node​

A participant in the Mina network that performs the consensus function, i.e., a block producer. For a node to participate in consensus, it requires the recent state.

Constraints​

Cryptocurrency​

A digital asset or currency that uses cryptographic primitives to secure financial transactions and to verify ownership via public-private key pairs.

Daemon​

The Mina daemon is a background process that implements the Mina protocol and runs on a node locally. This allows a local client or wallet to 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. It also listens for events like new blocks and relays this to the client via a pub-sub model.

Delegating​

Because staking MINA requires nodes to be online, some nodes may desire to delegate their MINA to another node that runs a staking service. This process is called delegating a stake, and often the service provider or staking pool operator may charge a fee for running this service, which will be deducted any time the delegator gets selected to be a block producer.

Deploy Alias​

A term used by the Mina zkApp CLI. This is an arbitrary name that is associated with details required during deployment, such as the destination GraphQL API URL, fee to be used, etc.

Epoch​

An epoch is a unit of time equal to 7140 slots at Mainnet. An epoch is divided into slots of 3minutes each.

External Port​

This is the port that the Mina daemon uses to connect to other nodes on the network. It can be set using -external-port when starting the daemon.

External Transition​

An external transition also referred to as a block, is a transition that is generated externally, i.e., by another block producer, and gossiped to a node.

Field Element​

A field element is 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 it 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 the point at which chain reorganizations are no longer possible. Once a block has k block confirmations, 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, i.e., by a block producer. The generated transition is applied locally and added to the transition frontier before being broadcast to peers.

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 and public key. Key pairs may be generated via a running daemon or using a dedicated keygen tool.

Mina​

  • "Mina" with a capital M references the underlying protocol and the network infrastructure that the system depends upon
  • "MINA" is the unit of the cryptocurrency that is exchanged by participating nodes on the network

Mina zkApp CLI​

A command-line tool available on NPM used to build zkApps that allows a developer to scaffold and deploy their smart contract.

Node​

A node is 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. When referring to the size of Mina as 22kb, this 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.

Peer-to-peer​

Networking systems that rely on peer nodes to distribute information amongst each other are called peer-to-peer networks. These networks are often distributed in nature, and unlike client-server networking models, do not rely on any centralized resource broker.

Pickles SNARK​

Pickles is a new 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. Read more.

Libp2p​

A peer-to-peer networking library that provides things like message broadcast and filesharing. Mina uses this under the hood.

Private Key​

The other component in public-key cryptography - private keys are held private while public keys can be issued publicly. Only the holder of the a 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. The protocol state comprises the previous protocol state hash to link blocks together and a body containing the genesis state hash, blockchain state, consensus state, and consensus constants.

Protocol State Hash​

The protocol state hash is the hash of hashes of the previous state and protocol state body. Acts a unique identifier for a block.

Proof of Stake​

The type of consensus algorithm Mina implements allowing nodes to agree upon the state of the network. Proof of Stake (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 which generates a zero-knowledge proof from your smart contract's logic.

Public Key​

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

Pub-sub​

Short for publish-subscribe, pub-sub is a a messaging pattern where message senders broadcast messages, and any listeners that have previously subscribed to that sender's messages will be notified. Mina utilizes this pattern, for example, as a way to notify clients when a new block has been added to the chain. This event can be "heard" by all listeners, and each listener need not independently poll for new data.

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 will need to 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. Once 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.

RPC​

A remote procedure call [(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.

Scan State​

The scan state is a data structure that queues transactions requiring transaction SNARK proofs and allows parallel processing of these transaction SNARKs by snark workers.

Signatures​

Short for digital signatures, signatures are a way to establish authenticity or ownership of digitally signed messages. This is possible because given a public-private key pair, the owner of the private key can sign a message and create a signature, which can then be verified by anyone with the associated public key.

Slot​

A slot in Mina is a unit of time. As of Mainnet launch, a slot 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 computer program containing arbitrary logic whose execution can be verified by a decentralized blockchain. On Mina, smart contracts are written with SnarkyJS.

SNARK Pool​

The snark pool contains work completed by snark workers for required work in the scan state. The snark pool, also referred to as the "snarketplace", only contains the cheapest work offered by snark workers for each work bundle. If cheaper, valid work is seen by the node, it will replace that already existing in the pool.

SNARK Worker​

A node on the network that is participating in transaction SNARK generation. The SNARK worker is incentivized to help compress transactions because they receive MINA as compensation for their efforts.

Snarked Ledger​

The snarked ledger is the ledger that only contains transactions that have an associated proof. The snarked ledger is updated once a proof has been emitted from the scan state that attests to all of the transactions included in a tree of transactions added via prior block producers.

SnarkyJS​

SnarkyJS is a TypeScript library for writing smart contracts based on zero-knowledge proofs for the Mina Protocol.

Staged Ledger​

The staged ledger is the current account state. It 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. The chance of winning the block scales in proportion to the amount of MINA staked. For example, if one node stakes 50% of the available MINA in the network, they theoretically have a 50% chance of being selected to produce future blocks. Mina uses Ouroboros Samisika Proof of Stake to implement the details of staking. If a node chooses to stake its MINA, it is required to be online and connected to the Mina network.

Staking Ledger​

The staking ledger is the ledger used to determine block producers for a slot, as the probability of winning a slot is proportional to the amount of stake. The stake distribution of the current epoch is the snarked ledger of the last block of the current epoch - 2.

Staking Pool​

A pool of delegated funds that is run by a staking pool owner. Other nodes may choose to delegate funds to a staking pool to avoid the requirement of being online.

Syncing​

To successfully produce a block that extends the Mina blockchain, a node requires the current state. To achieve this, a node will initialize 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.

Time-locked accounts​

An account with a non-vested amount of tokens that may not be moved until a specific condition has been met, such as a number of blocks, has been produced.

Transaction Pool​

A list of all pending transactions - sometimes referred to as the "mempool". Each node has a local transaction pool that contains transactions that have been gossiped to the node and validated. If the transaction pool becomes full, transactions within the pool may be evicted based on the fee, with the lowest being evicted.

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. It is a rose tree-type data structure as each "node" of the tree may have multiple children, i.e., forks. Each node in the tree is referred to as a breadcrumb.

TypeScript​

A superset of JavaScript that adds compile-time type safety. See the official TypeScript docs.

User Transaction​

A transaction issued by a user - either a payment or a delegation change

Verification Key​

A piece of data generated when building your smart contract. Sending this to a zkApp account is equivalent to deploying a smart contract and allows Mina to verify zero-knowledge proofs generated by your smart contract's prover function.

Verifier Function​

The function which verifies a zero-knowledge proof using the verification key.

VRF​

The verifiable random function (VRF) is used to select a block producer for a slot. It takes as input a random seed, derived from the previous epoch's VRF outputs, in addition to a public key and the current staking ledger and is deterministic, i.e., it will always return the same output regardless of how often it is run.

Zero-Knowledge Proof​

A proof by which one party (a prover) can prove to another party (verifiers) that they have knowledge of something - without giving away that specific knowledge. Mina uses zero-knowledge proofs, and specifically, zk-SNARKs, to generate a proof attesting to the blockchain's validity and allowing any node on the network to verify this quickly.

zkApp​

zkApps ("zero-knowledge apps") are Mina Protocol’s smart contracts powered by zero-knowledge proofs, specifically using zk-SNARKs

zk-SNARK​

A type of zero-knowledge proof - the acronym stands for "zero-knowledge succinct non-interactive argument of knowledge". The 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.