Currently, a 4-core processor and 8 GB of RAM are the minimum requirements. In the near future though, GPUs may be required.
Any node can send and receive transactions on the Coda network. Additionally, any node can choose to be a "Node operator". Node operators play two specific roles:
1) Block Producer - this is analogous to being a Bitcoin "miner" or a "validator" in other proof-of-stake networks. By staking coda, you can be selected to produce a block and win the block reward
2) Snark Worker - this job is what helps compress data in Coda's network. The snark worker nodes generate proofs of transactions, and the block producer buys these proofs on the network (we call it a "snarketplace" :)) - thus, the snark worker gets rewarded a bit of the block reward for their efforts.
The Coda testnet's goal is to improve Coda's stability, improve the software through bug fixes and addressing user experience, and to test the economic incentive design in Coda. By participating in the testnet, you get to be the first participants in the Coda protocol, and help develop it from ground zero.
Head over to the testnet landing page to learn more and get started.
First, check out Github issues to see if this is a known issue. If the error you experienced is a new issue, file a Github issue with the appropriate tags (daemon, bug). Coda developers will triage the issue and fix it in a future sprint -- thanks for your help!
Yes, check out the block explorer here: https://codaexplorer.garethtdavies.com/
Coda's consensus mechanism is an implementation of Ouroboros Proof-of-Stake. Due to Coda's unique compressed blockchain, certain aspects of the algorithm have diverged from the Ouroboros papers, and the version Coda uses is affectionately called Codaboros. Stay tuned for more details on Codaboros and some technical writeups on its details and implementation.
Coda achieves scalability through the use of recursive zk-SNARKs. By generating a proof that attests to the validity of historic blockchain states, Coda can keep the blockchain size fixed. This allows for increased throughput due to block size limits not being as taxing on the network, thereby increasing the scalability of the network.
Practically speaking, the limiting factor ends up being bandwidth, so it depends on the average quality of the internet connection among block producers. If the average connection is a symmetric 2MB/s, then it’s about 2000 tps.
The reason for developing a new protocol instead of offering services to other blockchains is because adding SNARKs after the fact to a Layer 1 project is not trivial. Even basic operations need to be optimized for performance inside a SNARK, and existing implementations are not able to be retrofit as such. If we look at hashing functions for example, SHA256 (used by Bitcoin) or Keccak (used by Ethereum) are extremely expensive inside a SNARK circuit, but Poseidon (what Coda uses) is optimized for performance. This and many other technical considerations make it infeasible to easily add recursive SNARKs to existing Layer 1’s, without entirely overhauling the base protocol.
It very likely will. However, it is far less of an issue than it was a few years ago. The Zcash team has done a lot of great work on improving the process, and it’s now possible to perform a multi-party computation (MPC) ceremony with hundreds of participants. There would only be issues if every one of those participants were to collude - if just one participant is honest everything is fine, so there is a lot more confidence in the modern approach.
Coda does not support smart contracts currently. The development team is looking into smart contract models, and it is on the roadmap for future development.
No, Coda does not natively implement privacy features at the moment. However, privacy is key consideration for cryptocurrencies, and is also on the development roadmap.
Block producers (the validators who add new blocks to the blockchain) are required to buy SNARKs from the network (or from what we call the Snarketplace) and will pay out some of their block reward as fees to the snark workers who generated SNARKs. This creates a secondary incentive mechanism in the network to reward nodes that help compress transactions.
No, they are different in several ways:
Snark workers will not need more storage or computing power over time. Snark workers simply query the mempool for pending transactions requiring Snark proofs, and then generate said proof -- this does not require syncing historical data. In addition, the underlying proving cost of Snark work doesn’t get more expensive with time.
If we are comparing Snark worker nodes with full nodes on Coda, then yes Snark workers will benefit from specialized hardware as generating SNARK proofs is currently compute intensive. Again, however, with the explosion of SNARK research, this is likely to change and become more accessible to consumer hardware.
SNARKs are a very overloaded term currently — when you read SNARK, it could be referring to the concept of succinct non-interactive proof systems (eg. SNARKs vs Bulletproofs), the specific technical implementation of the proof system (eg. the construction, the circuit, or the prover), or the individual instance of the proof itself (eg. the blockchain SNARK).
When we speak about it, we will try to adhere to using:
In economics, there is a pricing strategy called predatory pricing (or dumping) where one supplier of a product seeks to exhaust competing suppliers in the market by undercutting the market price. The supplier prices their goods much cheaper than the market rate, in order to drive out competitors, even if it means incurring short-term losses. Once the market has been cleared, the dominant supplier then increases prices above competitive market rates, as competition has been extinguished.
However, this strategy is only effective in markets where there are high barriers to entry. Meaning, competitors who were crowded out in the predation stage are unable to rejoin the market.
This is not the case for snark work, as the barriers to entry are low. Anyone who has spare compute can join the snarketplace and produce as little as one snark work, and profit on that unit of work. The only barrier to entry is the initial capital expense on hardware, but we anticipate hardware requirements to be low, such that users with spare equipment can come online and participate. If any snark worker succeeds in driving out the market and increases prices, it is anticipated that newcomers would reappear and drive prices back down.
No, provided that the snark work produced is still required by block producers, it doesn't matter who produced it first — only the price matters in the block producers' eyes. The caveat here is that earlier inclusion into the snark mempool is obviously beneficial, as block producers are likely to "see" the work earlier.
One could however envision a scenario where a set of snark workers are favored because they produced the most number of snark works that are profitable, and buying proofs from as few entities as possible would allow for more transactions to be included in any block.
There is also a threshold at which time becomes a factor, but this would only apply to very underpowered devices. We will follow up with detailed benchmarks, when we have run more tests.
Nope -- when a new block is generated, Coda computes the proof recursively over the prior proof and the new block. This is the advantage of recursive composition -- at any given time, nodes only need to store the most recent proof. Intermediate proofs are not needed. See this talk for more clarity on how this architecture emerged: https://www.youtube.com/watch?v=eWVGATxEB6M
See the section on running a Snark Worker in the Node Operator docs. TLDR; You can set an environmental variable (eg.
export OMP_NUM_THREAD=4) to limit the number of threads Snark Workers use.