Skip to content

Support FAQ

Joel Krauska edited this page Jan 17, 2019 · 18 revisions

Collection of frequently asked questions about coda and testnets.


Testnet Questions

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.


Clone this wiki locally