# Mina overview

> *This document is an overview on Mina, done while reading/watching [Mina docs](https://docs.minaprotocol.com), [ZK Hack Mina talk](https://www.youtube.com/watch?v=bjSAf41PWWI), [Technical Whitepaper](https://docs.minaprotocol.com/static/pdf/technicalWhitepaper.pdf), and [Economics Whitepaper](https://docs.minaprotocol.com/static/pdf/economicsWhitepaper.pdf).*

<div style="float:right;font-style:italic;margin-bottom:10px;">Research Group, 2022-02-10</div>
<br>

<div style="background: #f2f2f2;">

**Contents:**
[TOC]

</div>

## Main characteristics
- Succint L1 blockchain
- Recursive zkSNARKs in order to 'compress' the blockchain state into 22kb
- Kimchi: Plonk + Plookup

### Comparison to Ethereum
- Eth
- on-chain computation
- Mina
- offchain computation + onchain verification
- sent to network: state updates + zk-proof
- (network) nodes verify the proof + updates state onchain
- if zkproof verification fails tx is rejected

## Snapp
Snapp: UI + SmartContract
- SmartContract (Mina's SmartContract):
- Prover function: runs locally (browser). Generates the zkProof
- Verifications key: stored onchain to verify correctness of execution
- Deploying the verification key to the chain creates a _"snapp account"_
- Snapp methods
- Each method is compiled to a program which has:
- Input: method's arguments and onchain values
- other onchain contracts state, values from the state of the world (eg. BlockHeigh), etc
- Output: list of updates to perform and a list of preconditions related to onchain state


## SnarkyJS
- SnarkyJS is the way to write 'Snapps' in Mina
- Typescript library
- runs in the browser
- can use existing js/ts libs & tooling
- can use the Typescript type system, including Generics!
- can benefit from code editor's autocomplete features for Typescript
- Example of addition of two field elements:
- in js: `const sum = 1 + 3;`
- in SnarkyJS:

        const sum = new Field(1).add(new Field(3));
        const sum = new Field(1).add(3); // same than previous line but simplier

- It has a bunch of 'standard lib' Typescript types (which internally are translated into constraint system)
- Field, UInt64, UInt32, PublicKey, PrivateKey, Signature, Optional, Bool, ...
- State can only be derived from Field type
- The state (variables) of a Snapp are *public* unless explicitly stored as a commitment
- any argument of a method is *private* (unless eg. the method stores an argument directly in the state)
- Methods getting data from onchain, are *async* (using async/await js syntax)
- as the method who needs to fetch the current state of the snapp is running offchain
- Calling a method does:
- given some preconditions
- we compute the new state & generate the zkproof
- send the zkproof onchain + new state
- network verifies the zkproof + old state + new state
- Anatomy of a smart contract
- State variables (public)
- Constructor: how contract can be deployed
- Methods: updates & preconditions
- args are private by default
- Currently storage is onchain, but they have plans to have offchain storage
- eg: root stored onchain, the rest of the tree stored offchain in a decentralized storage
- SnarkyJS, the proof generation is WASM compiled from Rust code
- Recursion: Combine 2 different zkProofs into a single zkProof

### Account balances
- Mina has its own currency: Mina
- Snapp account balance accessible through `.balance`:

    // substract value from Snapp balance ('this' is inside the update method)
    this.balance.subInPlace(value);
    // add value to user balance
    user.balance.addInPlace(value);

- All balance changes in a tx must sum to 0

### Multisig example
- array of public keys (can be private)
- not stored onchain, stored as contract parameter (offchain)
- basically:
- 1. check if signer is in the defined array of pubKeys
- 2. check signature (& nonce non-reused)
- 3. allow the sender to decrease the balance of contract
- it is not public which pubK did a tx

## Mina Network
- Roles:
- Verifiers
- request Merkle paths (of the part of the state which the Verifier cares about) and check them
- Block producers
- Similar to 'miners' or 'stackers' in other protocols
- Incentivized by block rewards or fees paid by users
- Note: block producers are not incentivized by the threat of slashing in order to participate (due Mina's consensus mechanism)
- Individuals can stake, but also delegate their stake to another block producer
- For each tx added into a block, BlockProducers must SNARK an equivalent number of previously added txs (enforced by the consensus)
- they can produce those SNARKs themselves, or do it through specialized network participants: Snarkers
- Snarkers
- network participants who produce zkSNARKs that prove txs
- Snarkers post fees for their work
- if their SNARKs are used in a block, the BlockProducer pays fees to the Snarker from the total txs fees
- BlockProducers have the incentive to 'hire' Snarkers with lower fees, while Snarkers want to get maximum fee amounts
- This naturally forms a marketplace (aka. 'Snarketplace'), where participants compete to produce the most cost-efficient zkSNARK proofs.

## Other
- There will be a Mina->Ethereum bridge
- To verify inside an Ethereum SmartContract the Mina's state
- The other direction (Eth->Mina, verify Ethereum state inside Mina contract) not in the near future
- Mina zk 'tooling' is [Kimchi](https://github.com/o1-labs/proof-systems/tree/master/kimchi)
- which uses [Plonk](https://eprint.iacr.org/2019/953.pdf) + [Plookup](https://eprint.iacr.org/2020/315.pdf)
- Mina
- payment system is account based system
- consensus: PoS 'Ouroboros Samasika'

## Thoughts
- Seems that Mina focus is to provide Snapps tooling similar to what Solidity ecosystem currently is
- Abstracted from internals of zk, allowing devs to focus in the app level (similar to what Solidity does)
- If Mina is choosen as platform by Aragon&Vocdoni, it might be worth to train the devs into knowing to write Mina Snapps (in the same way that currently they know to write Solidity contracts)
- Some 'standard lib' components (circuits/gadgets) are implemented in Typescript as part of the SnarkyJS, but more computation demanding / complex ones are implemented directly in Rust (at Kimchi level) (similar to what 'precompiled opcodes' are in Ethereum's EVM)
- Snapps are designed to run in the browser (inputs & proof generation)
- Our initial use case is a zkRollup, which requires aggregating users txs/votes in a single proof by a server
- The feeling is that is Snapps are focused for app devs, like Solidity, apps running in user browser. But not for running your own infrastructure
- It could make sense to implement a DAO in a Snapp
- Similar to multisig, but offchain (with Mina's onchain execution, so for Mina chain assets)
- It would be like a 'L2/rollup DAO', where users can aggregate votes offchain (and the L1 would be Mina)
- Although Mina's SnarkyJS can be used to build needed apps, we would need deeper analysis in terms of our roadmap to actually know our best fit.
- As maybe depending on what we want to build it may make more sense to build it directly with [Circom](https://github.com/iden3/circom) (and other use cases would require more 'plonk' like stuff like [arkworks-plonk](https://github.com/ZK-Garage/plonk), [Plonky2](https://github.com/mir-protocol/plonky2) or [Halo2](https://github.com/zcash/halo2))

<!-- CSS hacks -->
<style>
/* CSS hack to add section numbers to titles,
starting from h2.*/
/* Titles numbers */
.markdown-body h1 {counter-reset: h2}
.markdown-body h2 {counter-reset: h3}
.markdown-body h3 {counter-reset: h4}
.markdown-body h4 {counter-reset: h5}
.markdown-body h5 {counter-reset: h6}
.markdown-body h2:before {counter-increment: h2; content: counter(h2) ". "}
.markdown-body h3:before {counter-increment: h3; content: counter(h2) "." counter(h3) ". "}
.markdown-body h4:before {counter-increment: h4; content: counter(h2) "." counter(h3) "." counter(h4) ". "}
.markdown-body h5:before {counter-increment: h5; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) ". "}
.markdown-body h6:before {counter-increment: h6; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) "." counter(h6) ". "}
.markdown-body h2.nocount:before, .markdown-body h3.nocount:before, .markdown-body h4.nocount:before, .markdown-body h5.nocount:before, .markdown-body h6.nocount:before { markdown-body: ""; counter-increment: none }
.markdown-body h1:before, .markdown-body h2:before, .markdown-body h3:before, .markdown-body h4:before, .markdown-body h5:before, .markdown-body h6:before {
color: #737373!important;
}

/* TOC numbers */
.toc ul li ul {
counter-reset: section;
list-style-type: none;
}
.toc ul li ul li::before {
color: #919191!important;
counter-increment: section;
content: counters(section, ".") " ";
}
</style>