Skip to main content
note

A new version of Mina Docs is coming soon! This page will be rewritten.

Staking & Snarking

Let's turn our attention to the other ways we can interact with the Mina network - namely, participating in consensus, and helping compress data by generating zk-SNARKs. By operating a node that helps secure the network, you can receive MINA for your efforts.

Participating in Consensus​

The Mina network is secured by Proof-of-Stake consensus With this model of consensus, you don't need to have complex equipment like in Bitcoin mining. By simply having MINA in our wallet, we can choose to either stake it ourselves, or delegate it to another node. Let's first see how to stake MINA ourselves:

caution

To properly remain synced to the network and participate in consensus, it is important that your server is running some form of a clock synchronization protocol. We recommend using NTP, which is relatively easy to setup and comes already installed as a default service on many popular linux distros.

Staking MINA​

We can try out staking with our MINA by issuing the following command:

mina client set-staking --public-key $MINA_PUBLIC_KEY

Alternatively, you can restart the daemon with the -block-producer-pubkey flag:

args={["-block-producer-pubkey $MINA_PUBLIC_KEY"]} />

We can always check which accounts we're currently staking with, by using the mina client status command:

mina client status

Mina daemon status
-----------------------------------

Global number of accounts:  372
Block height:               20
Max observed block length:  20
Local uptime:               1m48s
Ledger Merkle root:         ...
Protocol state hash:        ...
Staged Hash:                ...
Git SHA-1:                  ...
Configuration directory:    ...
Peers:                      5 (...)
User_commands sent:         0
SNARK worker:               None
SNARK work fee:             1
Sync status:                Synced
Block producers running:    1 (...)
Best tip consensus time:    epoch=0, slot=133
Next proposal:              None this epoch… checking at in 5.284h
Consensus time now:         epoch=0, slot=134
Consensus mechanism:        proof_of_stake
Consensus configuration:    ...
Addresses and ports:        ...
Libp2p PeerID:              ...

The Block producers running field in the response above returns the number of accounts currently staking, with the associated key.

caution

Keep in mind that if you are staking independently with funds in a account, you'll need to remain connected to the network at all times to successfully produce blocks. If you need to go offline frequently, it may be better to delegate your stake.

If you'd like to send your coinbase to an account other than the one that is staking, you can use the -coinbase-receiver flag when you start your daemon. You can even point the coinbase at a cold wallet!

Delegating MINA​

Delegating MINA is an alternative option to staking it directly, with the benefit of not having to maintain a node that is always connected to the network.

First make sure you've unlocked your account:

mina account unlock --public-key $MINA_PUBLIC_KEY

And then run this command to delegate your stake:

mina client delegate-stake \
    --receiver <DELEGATE-PUBLIC-KEY> \
    --sender $MINA_PUBLIC_KEY \
    --fee 0.1

The fields in this command:

  • The receiver flag is the public key of the receiver of your stake delegation
  • sender is the public key of the account from which you want to delegate
  • fee is the cost to send your transaction. It is paid to the network’s block producers.
  • Note there is no amount parameter. Your full Mina balance will be delegated automatically.

You'll notice that this command looks suspiciously like a payment transaction. That's because a stake delegation is also a transaction! This is why we have to pay a small transaction fee in order to change this setting.

Delegating your stake might be useful if you're interested in:

  • Running your own staking node that uses funds from a "cold wallet"
  • Delegating to a "staking pool" which will provide token payouts periodically
  • Or if you don't have enough tokens to make managing a block producer full-time worthwhile
note

There is a latency period of a 2-4 weeks before your new stake delegation comes into effect

Compressing data in the Mina network​

The Mina protocol is unique in that it doesn't require nodes to maintain the full history of the blockchain like other cryptocurrency protocols. By recursively using cryptographic proofs, the Mina protocol effectively compresses the blockchain to constant size. We call this compression, because it reduces terabytes of data to a few kilobytes.

However, this isn't data encoding or compression in the traditional sense - rather nodes "compress" data in the network by generating cryptographic proofs. Node operators play a crucial role in this process by designating themselves as "snark-workers" that generate zk-SNARKs for transactions that have been added to blocks.

You can start a snark-worker using these commands:

mina client set-snark-work-fee <FEE>
mina client set-snark-worker --address $MINA_PUBLIC_KEY

Alternatively, you can restart the daemon with these flags:

args={["-run-snark-worker $MINA_PUBLIC_KEY", "-snark-worker-fee <fee>"]}

As a snark worker, you get to share some of the block reward for each block your compressed transactions make it in to. The block producer is responsible for gathering compressed transactions before including them into a block, and will be incentivized by the protocol to reward snark-workers.

Snark workers can be fairly compute intensive, so if you need to limit their CPU usage, you can specify the number of threads snark workers use with the -snark-worker-parallelism flag. This can be especially useful if you're trying to run a block producer and snark worker on the same machine and having issues producing blocks in time.

That about covers the roles and responsibilities as a Mina node operator. Since Mina is a permissionless peer-to-peer network, everything is managed and run in a decentralized manner by nodes all over the world. Similarly, the Mina project is also distributed and permissionless to join. The code is all open source, and there is much work to be done, both technical and non-technical. To learn more about how you can get involved with Mina, please check out the Contributing to Mina section

Using daemon.json to configure your mina daemon​

By creating a file at ~/.mina-config/daemon.json, you can configure your mina daemon without needing to provide options on the commandline. This can be useful for running mina as a service as well as just for avoiding repetitive typing!

Most of the options that can be passed to mina daemon on the commandline can also be provided as options in the config file. See mina daemon -help for more documentation of the options. Below is an example of usage of all the usable configuration parameters (in your file, you only need to specify the ones you want to change):

{
  "daemon": {
    "client-port": 1000,
    "external-port": 1001,
    "rest-port": 1002,
    "block-producer-key": "/path/to/privkey-file",
    "block-producer-password": "mypassword",
    "block-producer-pubkey": "<MY PUBLICKEY>",
    "coinbase-receiver": "<MY PUBLICKEY>",
    "log-block-creation": false,
    "log-received-blocks": false,
    "log-snark-work-gossip": false,
    "log-txn-pool-gossip": false,
    "peers": ["seed-one.o1test.net", "seed-two.o1test.net"],
    "run-snark-worker": "<MY PUBLICKEY>",
    "snark-worker-fee": 10,
    "snark-worker-parallelism": 1,
    "work-reassignment-wait": 420000,
    "work-selection": "seq"
  }
}