---
title: Snark Worker
description: Details the role of the snark worker in the Mina protocol
tags: mina, candidate
---

# Snark Worker

While [block producers](https://hackmd.io/@garethtdavies/BkFFd6pdD) create [blockchain proofs](#) that prove the validity of the current state of the blockchain, they do not certify the included individual transactions.

Snark workers handle the task of creating these [transaction proofs](#). Offloading these transaction proofs from the block producer to snark workers means that the transaction proof generation may be parallelized, significantly improving the network's throughput.

When a block producer generates a block, they may include transactions recently seen on the network and included in the [transaction pool](#). The block producer includes these transactions in the [staged ledger](#) via a data structure known as the [scan state](https://hackmd.io/@garethtdavies/rkHUda6uP). For each transaction they add to the scan state, the block producer must add an equivalent amount of completed snark work from the [snark pool](https://hackmd.io/gHjzytCLT0qRUIGojZfxNQ#Snark-Pool). The snark pool contains completed transaction proofs submitted by snark workers for transactions added by prior block producers.

Snark workers charge a fee for generating these transaction proofs and are compensated by the block producers purchasing their completed snark work. A snark worker may charge any fee for the work they produce, but a block producer will (all things being equal) purchase the work required for the lowest fee.

A snark worker does not need the full state to operate and can run as a standalone process when paired with a [snark coordinator](https://hackmd.io/gHjzytCLT0qRUIGojZfxNQ#Snark-Coordinator).

:::success
A snark worker is run by adding the `-set-snark-worker <PUBLIC_KEY>` option to the `coda daemon` command or via the CLI via `coda client set-snark-worker -address <PUBLIC_KEY>`.
:::

## Work Selection

The snark work required is defined by the structure of the scan state. Newly added transactions from the block producer create pending work in the form of base transaction and merge transaction proofs.

Snark work is delivered in a work package, usually containing two work ids (the exception is the final merge proof of a tree in the scan state where there is only a single work id). Work ids are combined as each transaction included in a block will require the equivalent of two proofs due to the base proof and multiple merge proofs required, and as such, snark work is purchased in equal quantity to transactions included in a block.

In addition to any pending work that does not have an existing completed proof in the snark pool, a snark worker may choose work that they can complete for a lower fee. If they complete and broadcast the work before a block producer purchases it, this work will replace the higher fee work in the snark pool.

The Mina [daemon](#) includes two work selection algorithms, _sequential_ and _random_. The sequential algorithm processes new pending work in the order required by the scan state, whereas the random work selection algorithm chooses work in random order.

:::info
Modify the work selection algorithm using the `--work-selection` option of the `coda daemon` command
:::

## Snark Pool

The snark pool contains all the completed work submitted by snark workers. The pool only maintains the lowest fee for each work bundle as well as the public key of the prover. For example:

{
   "work_ids":[
      839740827,
      702578095
   ],
   "fee":"0.011",
   "prover":"B62qpEX1JXC7qNrC3bTwEEDU3UQGSE5DUVSenpmmLpLnNmwPDsLj8Jh"
}

The work required to be purchased by the block producer is derived by the [scan state](#) structure, and work must be purchased in a defined order. If there is no available snark work to purchase for a required work id, then no transactions will be included in a block (including the coinbase transaction). Additionally, a block producer will not purchase unprofitable snark work, i.e., the block producer may forgo a coinbase reward rather than spend more on snark work than they would receive. Typically, transaction fees cover the fees paid for purchased snark work.

All work received from other nodes is validated before it is added to the pool and is only added if the proof is valid, and it is the cheapest fee available. If invalid work is received from a peer, the sender is punished according to the [trust system](#). If work of an equal fee is submitted, the first seen work will remain in the pool and not be replaced.

For nodes joining the network, the snark pool is rebroadcast via locally created diffs every five minutes on a fixed schedule. Each diff is re-broadcastable for fifty minutes from the time it was added.

Once work has been included in a block, it remains in the snark pool for as long as it is referenced in the last `k` blocks of the scan state. After that time, the snark work is removed from the snark pool.

:::info
See the contents of the snark pool with the `coda advanced snark-pool-list` command.
:::

## Snark Coordinator

A snark coordinator coordinates snark jobs among many snark workers. The coordinator is responsible for sending new work to the snark workers, ensuring they do not duplicate the same work.

The snark workers communicate with the snark coordinator via RPC calls. New work is requested by a snark worker using the `get_work` RPC call. Completed work is submitted via the `submit_work` daemon RPC call. Once received, the coordinator broadcasts the completed work to the network.

A snark coordinator is run by providing the `-run-snark-coordinator <PUBLICKEY>` option to the `coda daemon` command. All workers using the same coordinator will use the same public key.

A standalone snark worker may be started using the `coda internal snark-worker` command by providing the `-daemon-address`, which is the client port of the daemon running the coordinator (default 8301).