High-level overview

--- title: High-level overview description: A high-level overview of the Mina protocol tags: mina, candidate --- # High-Level Overview Mina is a succinct blockchain that remains a fixed size as opposed to other blockchains that grow continuously over time. Due to its consistent size, Mina stays accessible and can be trustlessly accessed from any device, even as it scales to millions of users and accumulates years of transaction data. Mina achieves this by replacing the blockchain with an easily verifiable, consistent-sized cryptographic [proof](#). So, instead of end-users trusting intermediaries to provide accurate information about the ledger's state, they are given the state along with a zk-SNARK that cryptographically guarantees that the state is accurate. Mina uses a [proof of stake](#) consensus mechanism called [Oroborous Samisika](#), an adaptation of the [Oroborous](#) consensus mechanism for use in a succinct blockchain. Mina's native token is _mina_, which are subdivided into a billion _nanomina_. :::info For more information on the economics of Mina see the [economics whitepaper](https://minaprotocol.com/static/pdf/economicsWhitepaper.pdf). ::: ## Roles in Mina Mina has three distinct roles in the network, each incentivized to participate by different mechanisms. ### Block producers [Block producers](https://hackmd.io/@garethtdavies/BkFFd6pdD) are akin to miners or stakers in other protocols. Block producers create new [blocks](https://hackmd.io/@garethtdavies/SJ8s_ppuw), including transactions from the [transaction pool](#) while adding an offsetting number of completed [transaction SNARK proofs](#). They create a [blockchain proof](#) that recursively validates the prior state proof and proves the newly generated state's validity. This block is broadcast to peers and [gosipped](#) around the network. As a reward, they may receive a coinbase and any associated transaction fees for transactions included in the block. ### Snark workers [Snark workers](https://hackmd.io/@garethtdavies/Hk8_5cuYP) are responsible for creating transaction SNARK proofs, decoupling the proving of transactions from block producers. Snark workers compete in a market, aka the _snarketplace_, to submit the best bids for completed snark work. Block producers pay snark workers based on the bids for completed snark work required to include in a block to offset any transactions they add. ### Verifiers Verifiers are the equivalent of a _full node_ in other protocols. Verifiers do not participate in consensus but can request a balance of an account and verify this via the protocol proof that includes a Merkle root to a recent ledger state. By checking the Merkle path, verifiers ensure that the parts of the state they care about (such as their account balances) are indeed contained within the same ledger certified by the proof. ## Lifecycle of a payment A payment in Mina is a type of transaction requesting to transfer value from one account to another account, and the associated fee the sender is willing to pay for the payment to go through. :::info There are other types of transactions available in Mina, such as [delegation transactions](#). ::: As an example of how payments work in Mina, let's walk through a scenario where a sender, Bob, who has existing mina in their account, wants to send some mina to a receiver, Alice. * Using Bob's existing funded Mina [account](#), they [sign](#) and broadcast a transaction to peers on the network. * The transaction is gossipped between nodes and enters the [transaction pool](#) of nodes on the network. * The [block producer](#), when selected to produce a block, selects the transaction together with any additional transactions, completed snark work and fee transfers, generating the proposed next state of the blockchain. This action comprises updating the [staged ledger](#), which includes both a ledger and a pending transaction queue known as the [scan state](#). * The block producer generates a [blockchain SNARK proof](#) that certifies the newly generated state. * The [block](#) is then broadcast to peers and gossiped between nodes. At this time, while included in the staged ledged, the transaction does not have a [transaction SNARK proof](#). * [Snark workers](#) begin work on the transaction SNARK proofs for the included transactions in the scan state and submit their best bids for the work to the [snark pool](#) that may be purchased by block producers. * After several further blocks are produced and additional transactions have been included, a single ledger proof is emitted from the scan state. This proof is included in the blockchain SNARK generated by the block producer and attests to the validity of all transactions included in the [snarked ledger](#) - a ledger containing only those transactions that have transaction proofs. * The block reaches consensus [finality](#) and is dropped from the nodes, but Alice can validate the blockchain proof and trustlessly retrieve her account balance. Additionally, the individual transaction can be [later proven](#) without the chain history available. :::success Bob can send another transaction at any time and does not need to wait for either the transaction proof or the first transaction to reach finality. :::