Running a Mina Archive Node

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.

Introduction to the Coda Javascript SDK

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.

Consensus on the Coda Blockchain

This article is published on Medium.

Coda is a succinct blockchain where full nodes only require downloading and verification of a tiny proof to ensure that the state of the blockchain is valid. It achieves this through incrementally computed SNARKs where the latest block contains a proof that validates the new block in addition to the previous SNARK.

Coda utilizes a proof of stake (POS) consensus mechanism as opposed to the proof of work (POW) consensus mechanism popularized by Bitcoin. POS consensus algorithms have unique challenges, most notably the nothing at stake issue. Whereas in POW, miners are forced to complete work that expends energy and has a cost, in a POS system it is essentially free to participate, and an adversary can try different things to see what is favorable at no cost.

Running Coda with Docker

Docker provides one of the simplest ways of getting a Coda node up and running while providing the benefits of container isolation. It also resolves issues around dependencies on unsupported systems and allows specifying restart policies should the daemon crash.

It is important to use the correct image for each testnet release. The tags for all releases are available on DockerHub. For testnet 3.2b this tag is 0.0.12-beta-feature-bump-genesis-timestamp-3e9b174. This image is updated for each testnet, so the image used in the below commands should be updated accordingly.

At its simplest, we can start a Coda node with the following command. We’ll build upon this basic command for other Coda specific functions such as block production and SNARK workers.

$ docker run -d --name coda \
-p 8302:8302 \
-p 8303:8303 \
--restart always \
codaprotocol/coda-daemon:0.0.12-beta-feature-bump-genesis-timestamp-3e9b174 daemon \
-peer <PEER_1> \
-peer <PEER_2>

Read More

Prototyping a Coda Blockchain Explorer

This article is published on Medium.

A block explorer is a tool typically used to visualise the current and historical state of a blockchain including all transaction information. Coda, a succinct blockchain, presents some interesting challenges in this regard as this prior state information is not required to be stored by end-users or even block producers, but rather the protocol relies on cryptographic proofs to prove the current chain state (and thus everything preceding it).

Coda currently provides an option for users to run an archive node that persists block data. This data is then exportable via the GraphQL API and it is this data that has been used to produce a prototype block explorer to help users become better acquainted with the testnet and Coda’s functionality.

Prototyping a Coda Blockchain Explorer