Since it appears that this project is garnering a ton of attention on social media recently (on TikTok, specifically), it felt incumbent upon Librehash to ensure that due diligence is performed on this once-in-a-lifetime opportunity to obtain a cryptocurrency of epic proportions.

Despite the hype around this project on TikTok, there isn't too much information out about it (outside of its official channels), so that's where we'll start for good measure.

Visiting the Mina Protocol Website

The official Mina Protocol website can be found here: https://minaprotocol.com

Per their site, Mina Protocol states that they are, "The world's lightest blockchain, powered by participants" (aren't all blockchains de facto powered by participants as part of the 'peer-to-peer' characteristic that they're all supposed to feature?).

The website goes on to state that:

"Mina is building a privacy-preserving gateway between the real world and crypto - and the infrastructure for the secure, democratic future we all deserve."

The website goes on to boast the blockchain's tiny size (comparative to that of other blockchains that are currently in existence), in another statement on the site proclaiming, "By design, the entire Mina blockchain is about 22kb - the size of a couple of tweets. So participants can quickly sync and verify the network."

Deconstructing the Claim Mina Protocol is Making About Size

When it comes to blockchain, size is largely an inevitability since the blockchain itself is supposed to serve as a ledger for any and all transactions that have been mined in a block from its Genesis (first block) to the present time of examination.

However, even with this in mind, this still doesn't explain to us why blockchains are so large in size.

Below are the total blockchains sizes of a few popular Proof of Work-based projects: 340.21 GB

1. Bitcoin - 340.21 GB

2. Litecoin - 44.81 GB

3. Ethereum - 6.9 TB

4. Bitcoin Cash - 192.38 GB

You get the picture at this point.

Prime Contributors to the Block Size

It may be known that the sheer volume of transactions on these chains contributes to their overall block size, but that doesn't tell us what the prime contributor is.

Fortunately, that answer is easy to source.

Cryptography Signatures and Public Keys

Let's take a second and evaluate exactly how a Bitcoin wallet is constructed (on a technical level).

• First step is to generate a random seed (usually from entropy; "randomness")

• We're going to pipe that random seed into the ecdsa (secp256k1) formula to generate a private key for ourselves. Assuming that we're iterating Bitcoin keys in their 'compressed' form, the key that's generated must be 32 bytes

Above is a screenshot from the 'Bitcoin Forgein' tool, located here: https://improvein.github.io/bitcoin-forge/#/cryptography/keys

As we all know, the private key does not get stored on the protocol but rather a representation of the public key.

To be specific:

1. The public key is generated from the private key (by calculating the corresponding 'y' coordinate point for the 'x' [private key; generated from the 'G' generator point multiplied by the 'r' random value [derived from entropy] to [hopefully] manifest a "random" point on the curve)

2. The public key is a signed integer (i.e., you must decide whether its negative or positive). If you opt to make the public key positive, then you need to prefix it with '02', otherwise '03' must be prefixed to symbolize a negative value for the public key.

3. Iterate the SHA256 operation over the public key

4. Compress the public key down to 20 bytes by performing a ripemd160 operation on the SHA256 output

5. Prepend a version byte to signify the network the key is being generated for (i.e., '0x00' for the Bitcoin mainnet)

6. You then SHA256 hash the ripemd160 output (with the 0x00 byte prepended to it)

7. SHA256 the output of number six.

8. Take the first four bytes of the output of number seven (that's the first 8 characters in hexadecimal); write down these bytes on a piece of paper or take a mental note of them

9. Remember the original 20-byte output we generated from stage '4'? We're going to append those '4' bytes to the end of that output (keep the 0x00 prepended to the front of the ripemd160 result)

10. Serialize the address using base58check encoding (this is a special construction created just for Bitcoin

Other Facets of a Transcation

Let's take a quick look at your 'typical' run of the mill transaction to refresh ourselves:

source: https://bitaps.com/831d8df2136ef7ede3e20c366bfa1ce5c45d67afef664b4cbb1cbf5736c1b90d

In the screenshot above, the following can be observed:

1. There's one input transaction (sender)

2. There are six output transactions

Fortunately, Bitaps provides us with greater transaction details (i.e., the scripts involved), which allow us to count the total size taken up by just the addresses alone:

1. For the input, we can see that a total of 136 bytes alone

2. The output addresses, combined, account for 120 bytes

Altogether the addresses in this transaction account for 256 bytes.

However, this does not represent the totality of the transaction itself - we still need to identify how much size is taken by the signature in this transaction (mandatory for the transaction to go through; we know this because there is a 'op_equalverify', 'op_checksig' opcode directive at the end of 4 of those addresses.

Below is an illustration of the 'Script' smart contracting language for Bitcoin for transactions such as these:

As we can see, transactions like only resolve when the mandate for a signature that corresponds with the identified public key has been met.

Since BIP64, all Bitcoin cryptographic-related material is supposed to be encoded in 'DER' format.

source: https://en.bitcoin.it/wiki/BIP_0062

Therefore, the size of a transaction for a Bitcoin transaction must be 64 bytes (anything lower than that is a malformed signature):

Therefore, the average transaction for Bitcoin will come to a size of about 150-250 bytes (for a first-time send with no more than one input and one output [no change address]).

Evaluating the Preposterous Nature of Mina Protocol's Claim

In light of what was explained above, we should be incredulous of Mina Protocol's claim that they've figured out how to compress the size of their network's blockchain to no more than 2.2Kb total.

This total represents 14.5 of the smallest Bitcoin transactions (one input & one output). If we're looking at the gamut of transactions that have passed through the Bitcoin protocol, there are singular transactions that have exceeded this limit.

Compression World Records

To date, the world record for compression condenses information from sample Wikipedia pages (to serve as an ample writing sample to test the prowess of the compression algorithm submissions' effectiveness against bricks of real, legitimate English text).

Fabrice Bellard (world-renowned computer scientist), was only able to compress the sample down to roughly 10% of its total size.

source: https://bellard.org/nncp/readme-gpt2tc.txt

Taking all of this into consideration, we should be sufficiently excited to read into how the Mina Protocol has managed to expand former theoretical constraints for what was considered possible in the field of computing.

Recursive Snarks?

Upon clicking the link located on the Mina Protocol frontpage (titled, 'See the Tech'), we're taken to the following page: https://minaprotocol.com/tech

It is on this page where the 'secret' to the Mina Protocol's extraordinary compression ratio secrets are revealed:

In the photo above, the Mina Protocol team states:

"Rather than apply brute computing force, Mina users advanced cryptography and recursive zk-SNARKs to deliver true decentralization at scale."

Gaining a Better Understanding of Why Mina Protocol Believes Their Blockchain Can Be 2.2Kb

The misconception here is a bit comical (and very much akin to the one that Coda Protocol had a few years ago).

Evaluating Similar Claims by the Coda Protocol

For those that remember, the Coda Protocol similarly claimed that they were able to compress the size of the blockchain to just a few kb due to their use of Snarks.

Specifically, in their whitepaper (Abstract) Coda stated:

"We introduce the notion of a succinct blockchaikn, a replicated machine in which each state transition (block) can be efficiently verified in constant time regardless of the number of prior transactions in the system."

"Traditional blockchains require verification time linear in the number of transitions. We show how to construct a succinct blockchain using recursively composed succinct non-interactive arguments of knowledge (SNARKs)."

source: https://eprint.iacr.org/2020/352.pdf

Coda IS Mina Protocol

Turns out that, that faintly reminiscent feeling that struck us as we were reviewing the construction of the Mina Protocol wasn't just a feeling.

Public reporting from various 3rd-party sources reflect that, at some point during 2020, Coda decided to rebrand itself as the Mina Protocol.

source: https://medium.com/minaprotocol/coda-protocol-relaunches-as-mina-the-worlds-lightest-blockchain-269636e4b044

Sticking with that same press release (linked above), we can see that the Mina Protocol claims that, "Unlike first generation blockchains, such as Bitcoin or Ethereum, with heavy chains, Mina uses a chain that is, and always will be, 22 kb so participants can sync the entire chain in seconds.

Understanding Zero Knowledge Protocols

In the example that we gave for Bitcoin above, we constructed something that's similar to a "zero knowledge protocol".

In effect, by only mandating a signature that corresponds with a user's submitted public key (to spend a transaction), the blockchain is accepting the 'zero knowledge proof' that the holder of said public key & signature must also be in possession of the corresponding private key.

This is because the 'proof' generated by the secp256k1 elliptic curve construction allow for the key holder to construct their own proof that, when solved, provides mathematical reassdurance that said proof could have only been proven (i.e., signature provided) by virtue of owning or having access to the corresponding private key (satisfying the imposed transaction conditions to spend whatever unspent transactions are in limbo at this stage of the transaction process).

Deconstructing zk-SNARKs

zk-SNARKs stand for "Succinct Non-Interactive Argument of Argument" (in other words, a 'zero-knowledge proof').

However, rather than appealing to the inherent zero knowledge proof inherent in Bitcoin's construction, ZCash (the originators of this cryptographic scheme) decided to allow the sender of transactions to construct an entirely different (supposed more established) proof.

Digging into the Protocol's Technical Specifications

The whitepaper on zk-SNARKs (published by the ZCash Foundation), provides us with the technical specifications necessary to discern what data, if any, must be kept on-hand to prove the proof was ever met itself, in the first place (otherwise the trustless construction of blockchain that's designed to prevent double-spending is undermined in this cryptographic scheme's assumptions.

Digging into the Mathematical Foundation of zk-SNARKs

Per the whitepaper:

"We always assume we are working with a field F_r for prime r chosen according to a desired security parameter. We assume together that F_r we have generated groups G₁, G₂, G_t, all cyclic of order r; which we write G₁ and G₂ in additive notation and G_t in multiplicative notation."

From the above, we can assume that the 'numbered' "G" instantiations are the different scalar multiplicative values for some public / private key that you're looking to kill me over (or with).

Proving the MPC Construction

What makes zk-SNARKs unique as a zero-knowledge proof cryptographic scheme is that it instantiates a process know as 'MPC' (multi-party computation).

Specifically, the whitepaper for zk-SNARKs states:

"The protocol is conducted by n players, a coordinator, and a protocol verifier."

"In the implementation the role of the coordinator and protocol verifier can be played by the same server. We find it very useful to separate these roles, though, as the actions of the protocol verifier may be executed only after the protocol has terminated, if one wishes to reduce the time the players have to be engaged...."

Most important part here:

"...Any party wishing to check the validity of the transcript and generated parameters can do so solely with access to the protocol transcript."

In total, the protocol consists of four total 'round-robin' rounds.

The rounds are delegated as follows:

1. Round One = Commitments

2. Round Two = Revealing Commitments

3. Round Three = "After the random-powers subprotocol and the FFT, the MPC consists of a few invocations of the random-coefficient subprotocol. These invocations add a total of two rounds to the MPC, as sometimes and random-coefficient subprotocol will need the output of a previous random-coefficient subprotocol as input.

Reconstructing the Zero Knowledge Proof

It isn't enough to simply assert that the zero knowledge protocol has been iterated with a hash record acknowledging such.

Coda, like any other blockchain, can only retain legitimacy of the derived results themselves are auditable (and ZCash is).

Curiously, this auditability has been the primary contributor to ZCash's blockchain size (see below):

source: https://bitinfocharts.com/zcash/

In the chart above, we can see that ZCash, founded by Zooko (the creator of the zk-SNARKs concept) has a total blockchain size that well exceeds (22 kB).

$ZEC is currently trading above $250 at the time of writing (and there's a Grayscale Investment Trust for it as well).

Transaction Sizes For ZCash

Per ZCash's own website, we can see the average transaction sizes for both shielded and unshielded transactions:

• Shielded Transactions = 2000 bytes

• Unshielded Transactions = 500 bytes

Notably, shielded transactions account for more data than unshielded ones.

Given this information, how is it that the "Mina Protocol" proposes that they'll be able to construct a blockchain that's exponentially smaller than that of ZCash's when $ZEC has an active implementation of the same zk-SNARKs construction that Mina proposes will shrink the size of its blockchain down to no more than 22kb (ever, at any given point in time).

Going by ZCash's construction, that means that the maximum # of shielded transactions that can ever be present on the Mina Protocol at any given point in time (before the data is irrevocably erased, one must assume), is 11, tops.

Conclusion

Unfortunately for the crusaders of the Mina Protocol the plausibility of what they propose is out of the question (yet, ironically, creates several more questions about the integrity and competency of the 'Core' team behind Coda).