Skip to content

Support FAQ

Jump to bottom
Joel Krauska edited this page Jan 24, 2019 · 18 revisions

Collection of frequently asked questions about coda and testnets.

Testnet Questions

Seed Proposer Snark

Q: What is the difference between seed daemon, proposer daemon and snark daemon?

A: In a simple test cluster, you need a few basic components for the network to bootstrap and proceed. (seed, proposer, snarker) These can all run on the same machine for very simple testing.

The seed daemon is used to bootstrap the DHT peer discovery network. It is used as an initial central connection point to learn about other nodes on the network. In the mainnet, several seeds should be maintained all around the globe by the bigger community.

The proposer daemon is needed to propose new blocks (move the network forward). It collects transactions and proposes new blocks containing those transactions. This type of node will also do snark operations on the block and needs good compute capabilities.

The snark daemon is needed to processes and 'prove' each transaction and then merge proofs that 'prove' multiple transactions (recursive snarks). This node is very compute intensive. There's a trade off in scaling where more cores give faster wall clock time, but less efficient overall computation. In initial testing, we have found it's better to limit each snark worker to 8 cores. (different hardware may behave differently)

Q: How do I measure snark performance?

A: There's a profiler that can give some scaling guidance to better guide hardware choices for snarking.

coda transaction-snark-profiler

The final output number in seconds represents multiple snark operations, but should ideally be less than half of your CODA_PROPOSAL_INTERVAL.

You can limit the number of threads by setting the OMP_NUM_THREADS environment variable. export OMP_NUM_THREADS=8

Q: What should I set my CODA_PROPOSAL_INTERVAL to?

A: In our testnets we usually set this value to 60000 (60 seconds). This has each block advertised on a minute boundary which is very helpful for humans to debug/track/monitor. Our main net should be much faster, but requires more snarking capacity to complete.

Q: How do I know if the daemon is working?

A: A quick way to check if your daemon is running is to have the client send a status request. coda client status -daemon-port 8301 (default port is 8301)

This will report on how your current daemon sees the network. Important things to look at are the list of Peers (other connected nodes) and the block count. (you want to make sure blocks are increasing every proposal interval)

The other thing to check is for a coda.log file in your config directory. It captures daemon STDOUT and STDERR and is the best place to look if the daemon isn't responding and may have stopped.

Q: How do I figure out the command line options?

A: You can see all the current options for a command by using the keyword 'help' in your cli.

eg. coda client help currently shows:

Lightweight client process

  coda client SUBCOMMAND

=== subcommands ===

  batch-send-payments        send multiple payments from a file
  constraint-system-digests  Print the md5 digest of each SNARK constraint
                             system
  dump-keypair               Print out a keypair from a private key file
  dump-ledger                Print the ledger with given merkle root as a sexp
  generate-keypair           Generate a new public-key/private-key pair
  get-balance                Get balance associated with an address
  get-nonce                  Get the current nonce for an account
  get-public-keys            Get public keys
  prove-payment              Generate a proof of a sent payment
  send-payment               Send payment to an address
  snark-job-list             List of snark jobs in JSON format
  status                     Get running daemon status
  status-clear-hist          Clear histograms reported in status
  stop-daemon                Stop the daemon
  wrap-key                   Wrap a private key into a private key file
  help                       explain a given subcommand (perhaps recursively)

*** MiniCluster Q: How do I start a mini test cluster?

A: Here is a simple bash script to help initiate a trivial test cluster.

It may quickly go out of date, so consider it a work in progress.

#!/bin/bash

killall coda coda-kademlia exe
sleep 1
export CODA_PROPOSAL_INTERVAL=60000
PORT=8300
COMMON=" -txn-capacity 8 -ip 127.0.0.1"

while [ $PORT -lt 8600 ]
do
    CONFDIR="/home/codademo/conf-$PORT"

    rm -rf $CONFDIR

    CLIENT=$(($PORT + 1))
    EXTERNAL=$(($PORT + 2))
    PEER=$(($PORT + 3))
    REST=$(($PORT + 10))

    PORTARGS="-client-port $CLIENT -external-port $EXTERNAL -rest-port $REST"

    if [ $PORT -eq 8300 ]; then
        echo "Starting seed on port $CLIENT"
        EXTRAARGS=""
        coda daemon $EXTRAARGS $COMMON $PORTARGS -config-directory $CONFDIR > log-$PORT.txt &
        SLEEPTIME=10
        echo "Sleeping $SLEEPTIME"
        sleep $SLEEPTIME
    elif [ $PORT -eq 8400 ]; then
        echo "Staring proposer on port $CLIENT"
        EXTRAARGS="-propose-key secrets/high -peer 127.0.0.1:8303"
        coda daemon $EXTRAARGS $COMMON $PORTARGS -config-directory $CONFDIR > log-$PORT.txt &
    elif [ $PORT -eq 8500 ]; then
    echo "Staring snarker on port $CLIENT"
        EXTRAARGS="-run-snark-worker KNQxdQ2zGPN+xbEinl9//vVvVxIvI/I6UCXiYCj3Bu66afuhDHkBAAAA -peer 127.0.0.1:8303"
        coda daemon $EXTRAARGS $COMMON $PORTARGS -config-directory $CONFDIR > log-$PORT.txt &
    fi
    let PORT=PORT+100
done

sleep infinity
Clone this wiki locally