This article is published on HackMD.

Currently, when delegating to a block producer (aka validator) on MINA, the distribution of rewards is conducted off-chain, so block producers are responsible for calculating and distributing payouts according to their terms and conditions. Typical terms and conditions would include the fee percentage, the payout frequency, and perhaps the payout algorithm used. While the delegator’s funds are not at risk (you merely delegate the right to produce a block), a pool operator can steal any rewards in the worst-case scenario. The only recourse for a delegator would be to switch, which due to the latency involved in delegation transactions, would result in at least two epochs of rewards lost.

This article is published on Medium.

Mina is a succinct blockchain, which means while we can verify the chain’s current state using a zero-knowledge proof, the prior history is not retained. So, if we want to analyze the chain’s history (for example, to see individual transactions), we need to obtain it from an archive node. The official implementation of an archive node stores its data to a Postgres database, which typically requires the use of recursive queries to determine the canonical chain information.

This article is published on Medium.

Mina uses a proof of stake consensus mechanism with a block producer selection similar to Ouroboros, known as Ouroboros Samisika. The opportunity to produce a block for a slot is determined by a verifiable random function (VRF). This selection can be thought of like a lottery with each block producer independently running this function for each slot. If they get a VRF output greater than a threshold proportional to the producer’s stake, they get the chance to produce a block at the designated slot.

This article is published on Medium.

Mina is a succinct blockchain, and as a result, consensus nodes only store the recent history of the chain before discarding it (the last k blocks, currently 290). While prior transaction history is not required to prove the current state is valid (this is handled via a recursive zero-knowledge proof), many applications would like access to this prior transaction history. Examples include block explorers and wallets. To solve this problem, users may optionally run an archive node that stores a summary of each block seen in a Postgres database.

This article is published on Medium.

This post provides an introduction to the current implementation of the Coda Javascript SDK. Using the SDK, it is possible with Javascript to generate keys, sign and verify messages, and sign transactions that can be broadcast to the network. From the package’s Readme:

This is a NodeJS client SDK that allows you to sign transactions and strings using Coda’s keypairs. The project contains Typescript and ReasonML typings but can be used from plain NodeJS as well.