Mina's Adversarial Testnet, Testworld, is here!
Check it out



Testnet Status:


Archive Redundancy

Presented here are three flows for accessing historical information about blocks and transactions.

The paths presented here are sorted from "rawest" to "most processed".

O(1) labs will be deploying all three flows in their infrastructure (with lots of redundancy) so they will be able to provide missing information for consumers of (A), (B), or (C) if their nodes go offline for any reason and miss information.

A. Raw Block Logging

We have a mechanism in place for logging a high-fidelity machine-readable representation of blocks using JSON including some opaque information deep within. We use these logs internally to quickly replay blocks to get to certain chain-states for debugging. This information suffices to recreate exact states of the network.

Some of the internal data look like this:


This JSON will evolve as the format of the block and transaction payloads evolve in the network. Though we don't expect much churn before mainnet.

This information is exposed via a structured log and fed to stdout. We can supply filtering tooling for capturing just these messages so they can be safely and permanently stored.

B. GraphQL JSON Snapshotting

The Mina daemon hosts a GraphQL server on port 0xc0d or 3085 (by default, configurable via config file or -rest-server-port flag) to this machine (you can make it open to with -insecure-reset-server). It is not safe for this port to be open to the public internet.

We expose a bestChain query that will remain able to get at least the last few blocks (though not all of them) see the docs here for more: https://minaprotocol.com/graphql-docs/query.doc.html that should have all the information you need in JSON. If you poll this at a rate faster than every 3minutes, you will keep up with every block. You can also get this same information via subscription pushed to you via https://minaprotocol.com/graphql-docs/subscription.doc.html .

Currently both many applications exist on testnets that consume this information. O(1) labs is relying on this data source in a few places and there will likely be other consumers by mainnet.

C. Official Archive Node PostgreSQL

O(1) labs will support recovering missing data here from both (B) or (A) backups.

The nice thing about the archive node is there are already consumers relying on queries for "what is the block at height N on the canonical chain". See https://minaprotocol.com/docs/archive-node for more info.

  (SELECT ... FROM blocks b WHERE height = (select MAX(height) from blocks)
  ORDER BY timestamp ASC
  LIMIT 1)


  SELECT ... FROM blocks b
  INNER JOIN chain
  ON b.id = chain.parent_id AND chain.id <> chain.parent_id
) SELECT ..., pk.value as creator FROM chain c
  INNER JOIN public_keys pk
  ON pk.id = c.creator_id
  WHERE c.height = ?

This can be tweaked to get all blocks within a window or all transactions within the blocks within a certain slice.


Liquid Balance Details:

All (A), (B), (C) have enough information to compute liquid balances for vesting accounts.

If you'd like to expose liquid balances for vesting accounts at some particular time period it is governed by the following function (Note: this computes the locked portion of an account):

 *  uint32 global_slot -- the "clock" it starts at 0 at the genesis block and ticks up every 3minutes.
 *  uint32 cliff_time -- the slot where the cliff is (similar to startup equity vesting)
 *  uint32 cliff_amount -- the amount that unlocks at the cliff
 *  amount vesting_increment -- unlock this amount every "period"
 *  uint32 vesting_period -- the period that we increment the unlocked amount
 *  balance initial_minimum_balance -- the total locked amount until the cliff
let min_balance_at_slot ~global_slot ~cliff_time ~cliff_amount ~vesting_period
    ~vesting_increment ~initial_minimum_balance =
  let open Unsigned in
  if Global_slot.(global_slot < cliff_time) then initial_minimum_balance
    match Balance.(initial_minimum_balance - cliff_amount) with
    | None ->
    | Some min_balance_past_cliff -> (
        (* take advantage of fact that global slots are uint32's *)
        let num_periods =
            Infix.((global_slot - cliff_time) / vesting_period)
            |> to_int64 |> UInt64.of_int64)
        let vesting_decrement =
          UInt64.Infix.(num_periods * Amount.to_uint64 vesting_increment)
          |> Amount.of_uint64
        match Balance.(min_balance_past_cliff - vesting_decrement) with
        | None ->
        | Some amt ->
            amt )