@_jillruth Our mission at Coda is to make it possible to write software that can be held accountable by users. We see a cryptocurrency protocol which can be verified by anyone as being a first step toward that future by providing everyone with the functionality of an irrevocable public ledger and state.

Here are some examples of how that could be used: a social network that lets you see exactly where your data is going and who has access to it; browser extensions that make sure your password is being handled securely (like the lock for HTTPS); advertisements that prove they aren’t targeting against you based on your race or economic status; automating compliance with privacy regulations like GDPR; fully verifiable and auditable elections.

@_jillruth @atyreefinch We’ll be starting soon to look into a smart contract layer for Coda. The VM itself will likely be Turing complete (with a general purpose language to match), but we are also planning on offering a set of higher-level DSLs to simplify and provide better security for specific use cases.

@izmeckler are you aiming to be a Turing complete (or nearly Turing complete) platform?

@cyounessi1 As we mentioned in response to @jonathanmarcus's question, it would be extremely difficult to incorporate our architecture directly into other blockchains because many careful choices in the design of a protocol need to be made in order to be compatible with SNARK-ification (and a compact architecture). With regards to your other question, the primary tradeoff isn't security (the use of zk-SNARKs makes the security equivalent), but computation. Fortunately, in Coda we have the entire network incrementally producing the snark proof for the blockchain, so the work is spread out, and both individual and total validation work is far reduced. For most users the security should actually be better, as they can run the equivalent of full nodes without any overhead.

@pilcowitz We definitely agree with those priorities, it’s extremely important to us that we’re doing is accessible and legible. To accomplish that we’ve developed and are using snarky, a high level programming language for writing zk-SNARK programs. The benefit is that the code written using snarky is almost equivalent to the code you would usually write to verify a blockchain. The only difference is that instead of running the lengthy and intensive program as usual, you can effectively run it for free.
We also want that these techniques to be as understandable and accessible as possible, without relying on an understanding of advanced cryptography and mathematics. We’ve found analogies such as thinking of a SNARK as passing around a photo instead of the entire object go a long towards making things understandable. Some of the concepts may rely on some advanced mathematics, but their functionality is relatively simple to understand. We’re hoping this approach gets as many people engaged and involved in secure verification as possible!

@dstuecken The key is a new application of zk-SNARKs. They're a cryptographic technology (used in ZCash and recently given some support in Ethereum) that enables the creation of tiny proofs (~ 1 kB) which can stand in for arbitrary computations (like verifying a blockchain). Combined with a technique called recursive composition (think “I know a proof that knows a proof that knows a proof…”) these proofs can be produced incrementally as the network operates.
The Coda protocol uses a zk-SNARK that proves a blockchain is valid to stand in for the old way of verifying a blockchain (downloading and locally evaluating the gigabytes upon gigabytes of transaction history). The ~19 other kB are necessary for providing a Merkle path into the balance of a particular account, so ~20 total for the proof + an account balance.

@soonaorlater Put simply, Coda makes cryptocurrency accessible to everyone. It overcomes the requirement to download every transaction that has ever happened to verify a blockchain. This is a big difference, because most people can’t download gigabytes upon gigabytes of data before using a blockchain.

@jonathanmarcus Practically speaking, making a blockchain fully succinct requires choosing the cryptographic primitives (hash function, signature scheme) in a very careful manner from the start. That’s because they need to be efficient to execute inside a zk-SNARK. And for blockchain protocols which allow explicit reference to history, it would be impossible without a massive protocol redesign from the ground up.

@izmeckler Makes sense, thanks Izaak!

@srinitude I’m glad you asked! Our engineering team believes that the safety and clarity statically-typed functional programming techniques are important for fast iteration while maintaining correctness. OCaml’s type system makes it easy and fun to write correct programs. About the other languages you mentioned: Python is dynamically typed. This means that errors and even typos can easily make it into production. C++ is a bit scary, as it’s very easy to introduce memory errors and vulnerabilities, and also does not provide useful facilities for abstraction (pattern matching, algebraic data types, modules, etc.). Scala is a pretty good functional language -- but the kinship with Java introduces some unnecessary cruft (and the overhead of running on the JVM).

@srinitude @izmeckler Thanks for your well-thought out answer, Izaak! Just followed you on Github :)

@rasnhop There are lots of interesting ideas out there for scaling solutions, like increasing block size or somehow restricting the set of block producers, which mainly focus on increasing throughput. But by default, high throughput introduces a big risk of centralization that will make it dramatically more difficult for normal users to ensure that everyone’s playing by the rules. Thousands of transactions-per-second translates to terabytes of data per week; and only those with the resources and incentives to do so will be able to obtain and check it themselves.

In Coda, users don’t need to see the transactions themselves, but rather only a tiny proof, breaking this tendency toward centralization when increasing throughput. On a technical note, we are able to pipeline and parallelize SNARK construction to stuff a very large number of transactions in each block.

In sum - by overcoming the tension between scalability and decentralization, Coda opens the door to increased throughput (like increasing block size or alternative consensus mechanisms) without harming accessibility.

@rasnhop @izmeckler Will Coda be able to do millions of transactions per second as I see that as needed for whole world adoption?

@FaraazNishtar It very likely will; However we view that as 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 setup 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 we can have a lot more confidence in the modern approach.

@Brian-Tinsman The base protocol that we’re describing isn’t a privacy coin, so if someone wanted to they could listen to the network and store a history of transactions. In fact, we’ll probably do so for monitoring purposes and allow people to download copies if they’d like to do research.

@sitonakamoto No public tokenomics plans yet, but we're striving for a wide distribution

@wcarzt Mostly answered above (see @BrianTisman's post) - yes! Anyone will be able to do so if they’d like, we’ll probably do so and allow people to download copies for that purpose

@BlockEnthusiast Exactly. Our use of zk-SNARKs is primarily for enabling the succinct blockchain. We are looking into adding smart contracts later which we expect will have zk-SNARK support, so some form of privacy as a smart contract application should be possible.