Various Crypto Market Statistics and Project Measurements (Pt. 1): Analyzing a Crypto Project From the Backend

In this piece, we’re going to take a look at various market statistics and metrics from numerous different sources (all will be cited so that you can follow-up on them on your private time).

Crypto Project Coding Activity

This metric attempts to assess how ‘active’ a crypto project is on the development side of things by assessing the total number of commits pushed through to its GitHub over a given time frame (i.e., 24 hours/1 week/1 month etc.)

Warning: This is a ‘Gameable’ Metric

Unfortunately, some projects have become acutely aware of the fact that there are various entities in the crypto space that are attempting to use this metric to assess the level of ‘productivity’ of a given project in the crypto space — so they have decided to post ‘empty’ commits that have no real impact on the code in order to increase their rankings in these kinds of metric comparison.

Thus, the only way to truly know whether a project is being as productive as their GitHub commit numbers project they are, is to dive into the project’s actual GitHub and take a direct look at the project’s code and associated updates.

Coincodecap

The first source that we’ll use in order to assess this information is ‘Coincodecap’ (site = https://coincodecap.com/).

Below is a quick look at the website (this is what you should see upon entering the site):

As we can see above, ‘Coda’ is the top project right now in terms of ‘activity’ (note that there is another slot for the ‘overall rank’).

Let’s take a closer look at ‘Coda’.

Taking a Closer Look at Coda’s Development Activity

Source: https://coincodecap.com/project/Coda

So far, it looks fairly normal.

One point of concern, however, is the 517 open issues.

For those that aren’t too familiar with GitHub (the website; Github.com), ‘open issues’ are generally bugs/questions/issues/glitches/etc., that are typically reported by users and also developers on the project itself.

The purpose of utilizing the ‘open issues’ feature of GitHub is to alert the maintainers of the project of a given issue or problem.

Generally, these issues are ‘closed’ once they have been addressed in some facet.

This is done to:

  1. Notify the reporting entity/individual that the issue has been acknowledged, addressed and (hopefully) fixed
  2. Notify other team members that someone is already working on the issue
  3. Organize the project as well so that the issues that are still ‘open’ serve as an accurate reflection of what problems/issues/bugs/etc., have actually not been addressed.

Occasionally, there are development teams that have actually responded to a given issue and they may have even resolved some of the problems brought to their attention in the ‘open issues’ tab of GitHub, but they simply haven’t taken the time to actually close the open issue.

The most likely reason for why this occurs is laziness.

Yes, laziness.

Let’s see what’s going on with Coda!

Coda’s GitHub

Prologue

Wait, wait! Before you go any further! I don’t know how to read code! I can’t program! I’m just your average humble bumble Bryant Gumble! This is going to go way over my head!

Do not worry. The author of this article is far from a coding guru. The author of this article has never:

  • Coded up a blockchain project
  • Worked as an engineer/developer in any professional/freelance setting — ever
  • Learned anything that they didn’t find out first on Google — and by Google, we mean literally Googling, ‘What does this function mean?’

Seriously though, don’t be intimidated by this stuff. The fact that you even decided to click on this article and read this far shows that you have more than enough interest to grasp what’s going on and more than likely, you’re VERY qualified to understand what’s going on.

That isn’t coming from someone that has a PhD in Computer Science that’s so adept at programming and development that they grossly overestimate the abilities of the ‘average joe’.

This is coming from an Average Joe.

Back to Coda!

Coda’s primary GitHub account (maintainer; i.e., the account responsible for overseeing the different parts of the project’s code) is titled, ‘Coda Protocol’, and can be found here: https://github.com/CodaProtocol

Overall, there are 21 repositories related to the Coda project.

They are (yes, we’re going to list them out  this is a good exercise if you’re not that familiar with GitHub, code or any of this technical stuff):

  1. Coda
  2. Coda-automation
  3. homebrew-coda
  4. rpc_parallel
  5. coda-python-client
  6. async_kernel
  7. coda-grants
  8. graphiql-with-extensions
  9. pairing
  10. snark-challenge-prover-reference
  11. kademlia
  12. snark-challenge
  13. gpu-groth16-prover-3x
  14. cuda-fixnum
  15. orocksdb
  16. snark-challenge-cuda-starter
  17. digestif
  18. testnetc2
  19. ppx_deriving
  20. ocaml-extlib
  21. ppx_optcomp

We’re going to start with the very first repository, ‘Coda’ (for obvious reasons).

Examining the Coda Repo

As hyperlinked above (twice), the ‘Coda’ repository can be found here: https://github.com/CodaProtocol/coda

When you click on the link, your page should look like this:

What the Hell Does ‘Coda’ Do?

It would probably help to know the answer to this question before proceeding any further.

So let’s bite, and check out the link that they have posted for us at the very top where it states:

“Coda is a new cryptocurrency with a constant size blockchain, improving scaling while maintaining decentralization and security. https://codaprotocol.com

‘Coda Protocol’ Website

The frontpage (at least as of October 12th, 2019), gives a pretty good gist of one of the alleged benefits of Coda (yeah, alleged, because we do not know yet — that’s why we’re doing this excercise!).

Here’s the frontpage (with some annotations on it):

Explaining the Annotations

In relation to the ‘2 TB+’ claim for other blockchains (we’re going to assume that Coda is stating other projects are that size), that number is greatly exaggerated (by miles).

Let’s take a look at the size of some of the most popular blockchain projects (at the time of writing; October 12th, 2019)[data provided by Blockchair.com]:

Bitcoin (244.13 GB)

Ethereum* (105.97 GB)

Bitcoin Cash (143.89 GB)

You get the picture by now.

This may be nitpicking — but it is worth noting when there are comparisons drawn between a blockchain project and other blockchains that blow the ‘other’ blockchains’ problems way out of proportion (like Coda did on their site).

Reasons For Why Coda’s Claim of a 22kb Chain is Incredible (and almost unbelievable)

This issue goes to the heart of how blockchain (typically) works.

Beyond the idea of a chain’s consensus algorithm (i.e., Proof of Stake/Proof of Work/etc.), is the composition of its transactions.

On Bitcoin, for example, each transaction consists of header data:

The pictures above shows the type of information that is usually included in each Bitcoin transaction.

Overall, this information adds up to about 200–250 bytes per transaction (smallest TX on the Bitcoin protocol can only be 100 bytes).

The ‘keys’ and ‘signatures’ account for the bulk of the TX size and that’s attributable, in a large part, to both the ECDSA curve Bitcoin uses (secp256k1) as well as the SHA256 hashed output of public keys.

Various measures such as compressing said public key have helped to a certain extent in terms of cutting down on the size of the transactions, but there’s only so much that can be done without completely altering the way the protocol functions.

So, in analyzing Coda, we’re going to look at:

  1. The cryptography that this project uses
  2. How blocks are formed, what the protocol rules are, and where things are stored
  3. How public keys are created and how the protocol operates

Hunting Down Cryptographic Information as it Pertains to Coda

Going back to the main ‘Coda’ repository — there isn’t much information in the way of cryptography.

So, we were forced to take a brief detour to the Coda whitepaper to get a better idea of what it is they’re trying to do here.

Brief Look at the Coda Whitepaper

In case you’re also looking, the Coda whitepaper can be found here: https://cdn.codaprotocol.com/v2/static/coda-whitepaper-05-10-2018-0.pdf

We won’t waste too much time here, so let’s dive right into it.

Succint Blockchain

According to Coda’s whitepaper, in order to create a blockchain protocol that, ‘achieves both scaling and decentralization’, the developers decided to make Coda a “succinct blockchain”.

In the paper, a ‘succinct blockchain’ is defined as:

“A blockchain for which verifying the current world state requires only a constant amount of data and a constant amount of time. Concretely, a user of Coda requires only 20 kilobytes and about 10 milliseconds to verify their balance. These requirements are independent of the number or complexity of the transactions processed by the blockchain. This allows Coda to scale to large numbers of users while staying accessible to those with relatively limited computing resources.”

The paper further states:

“Coda’s succinct blockchain is enabled by recursive composition of zk-SNARKs [BCCT12]. Recursive composition of SNARKs enable constant-sized proofs of arbitrary, incremental computations. This allows the Coda network to construct a proof of the validity of blockchain state that can be updated incrementally as more blocks are added.”

Before we dissect the information above (fully), let’s see if we can’t find out where more information (in the source code or elsewhere) can be located.

Continuing Our Search for Coda’s Cryptographic Outline

Stumbling on the ‘Coinlist’ link for ‘Coda’ ( https://coinlist.co/build/coda)

Through some cursory Google searching (and searching on GitHub) the above webpage was sourced.

Scrolling down from there (the top), we can see:

Above is our jackpot.

We have:

Coda SNARKs Documentation

The Coda SNARKs Documentation link takes us here: https://github.com/o1-labs/snarky

Noticeably, the URL (and the GitHub) shows us that this repository is controlled by ‘o1 Labs’, which was the name of the second link provided above.

So, let’s checkout o1 Labs and see who they are and what they do.

[site = https://o1labs.org/]

o1 Labs Gloss Over

Here’s a view of the homepage we got when visiting o1labs.org :

Surprisingly, the page doesn’t really give us a lot of information about what’s going on — so its back to the first repo to see what we can glean from the GitHub.

Fortunately, the GitHub provides us with some more information about what it is ‘Snarky’ does in the Readme.md (already open on the main page of the repo).

Specifically, it mentions ‘R1CS SNARKs’, stating that it is, “Modular over the backend SNARK library, and comes with backends from libsnark.”

[Link for libsnark = https://github.com/scipr-lab/libsnark ]

ZKP.Science

A cursory look on the internet (outside of the GitHub that we were just in) for more information about ‘R1CS SNARKs’ took us to ‘zkp.science’.

There are a ton of resources on this page, in general, so this is probably worth saving for all those that are interested.

Looking Up More Information About ‘Recursive SNARKs’

This is critical since Coda listed this as the underpinning of its innovation in the whitepaper where it states:

“Coda’s succinct blockchain is enabled by recursive composition of zk-SNARKs [BCCT12]. Recursive composition of SNARKs enable constant-sized proofs of arbitrary, incremental computations. This allows the Coda network to construct a proof of the validity of blockchain state that can be updated incrementally as more blocks are added.”

A cursory search for more information regarding ‘recursive SNARKs’, brings us to an informative forum post on ethresear.ch concerning their implementation (see below):

https://ethresear.ch/t/reducing-the-verification-cost-of-a-snark-through-hierarchical-aggregation/5128

The article cited in the post can be found here: https://eprint.iacr.org/2014/595.pdf

Its a research study titled, ‘Scalable Zero Knowledge via Cycles of Elliptic Curves’.

No coincidence, this is exactly what Coda is trying to do.

Breakdown of the Process via Illustrations

Since the forum post does such a good job dissecting how recursive SNARKs would be implemented on chain, it only seems logical to provide the same illustrations below to assist readers in comprehending how Coda plans on implementing its plan.

The leaf nodes (ie: the batch of proofs to be aggregated together) are inputed as:

A verification key

A proof

A primary inputs of the the proved assignement [sp]

In theory, this could work — but its hard to imagine that every node would be able to verify all transactions on the chain, maintain the state and never need to cache more than 22 kb of data, regardless of the process being run, on a protocol that retains the features of trustlessness/decentralization/distribution (all three requisite in creating a superior solution to Bitcoin).

This is especially true when considering the size of the key signatures that would more than likely be deployed for such a solution.

The remainder of the forum post we referenced above does a great job in tackling that aspect of the idea as well:

Source: https://ethresear.ch/t/reducing-the-verification-cost-of-a-snark-through-hierarchical-aggregation/5128

Coda is Still on its Testnet

Unsurprisingly, such an ambitious protocol is still on its testnet (as it should be given the grandiose cryptographic scheme it is attempting to deploy).

Questions of security, robustness, decentralization, fidelity to the property of ‘trustlessness’, etc., more than likely still look in the air at this point.

However, for those interested, more information about the Coda testnet can be found here: https://codaprotocol.com/testnet.html

https://codaprotocol.com/testnet.html

Quick Look at the Documentation

It appears they don’t have a deployment for Windows yet, which is a bummer since most computer users own a Windows machine.

This isn’t prohibitive for a robust network, but it does hurt.

The requirements for the device to have at least 16 GB of RAM is actually somewhat steep. That indicates that this blockchain requires a considerable amount of processing power allocated to nodes running on it, even in its beta testnet form.