-
Notifications
You must be signed in to change notification settings - Fork 547
Support FAQ
Collection of frequently asked questions about coda and testnets.
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:
A: