Removing the need for trust
An example of how we can remove the need for trust through technical design and implementation
Motivation
From 2020 to early 2022, a lot of people were interested to learn about web3 and crypto.
Fast forward to today, if one talks to anyone on the street about web3 and crypto nowadays, chances are, one will get the following responses — “crypto is a giant ponzi scheme” and “it’s only used for illegal activities”.
It is understandable why the public feels this way.
The negative news and the material losses from segments of web3 bring a lot of fear and disdain for the industry as a whole. (eg. the infamous FTX)
All this is to say, a certain segment of the industry breached the trust of the public.
This article will dive into not just how to build trust but an angle on how to remove the need for trust in general through engineering.
Problem
One of the biggest problems in finance, be it in decentralized or centralized finance, is trust. When there is a way to profit from dishonesty, certain people will take that route.
Many today have heard of FTX, but this is not a new problem. Mt. Gox was a notable example where bitcoins on the exchange were stolen. (Read more here)
Because of the magnitude of the fiasco with FTX, Terra, Celsius, etc., the risk has become simply too great for retail investors and users. This attracted a very heavy-handed approach from regulators on the entirety of the industry. For example, a former Paxos exec mentioned that regulators are going after on-ramps (read more here). This could only mean one thing — regulators don’t want you touching crypto at all (not even on-ramping).
Given that some people have the inclination to be dishonest, a technical solution is needed where we remove the need to trust.
This is where the concept of proof-of-reserve comes in.
What is PoR (proof-of-reserve)?
Proof-of-reserve is a mechanism that allows users to verify that a financial institution or service provider actually holds the assets it claims to hold.
It is typically used in the context of cryptocurrency exchanges, which are often accused of operating fractional reserve systems where they hold only a fraction of the assets they claim to hold.
A digression: Fractional Reserve
You might ask — doesn’t tradfi (traditional finance) have a fractional reserve as well?
Yes, it is how the traditional system works after the 1933 Banking Act motivated by the 1929 stock crash and the onset of the Great Depression. Essentially, ordinary banks are FDIC insured. Thus, if there is ever a bank run like the ones happening in crypto right now, you’d be covered up to $250,000 in ordinary cases. (See here)
However, crypto exchanges and banks are not FDIC insured. This has to do with some of the problems (non-exhaustive) below:
- The technology is very different and esoteric from anything we’ve seen before. Very few people understand it deeply.
- This runs aground with the federal reserve system as it not only creates an entirely new system but also is motivated by the rejection of centralization (a centralized entity that can manipulate the money supply and demand via Federal Funds Rate).
- There is an image problem as what many know crypto as a means for illicit transactions (e.g., money laundering. See Tornado Cash)
- Exacerbated by years of easy monetary environment motivating more speculative purchases of tokens, coins, etc. (and of course, it’s natural that losses led to disdain)
Continuing on the main topic
Thus, before this industry gets its blessing (otherwise known as regulation) from the government, it is left on its own to prove to the world that it is a viable system by providing a technical solution.
(Here’s a great blog on the PoR landscape)
Technical Overview
At a very high level, proof-of-reserve involves providing users with cryptographic evidence that shows the exchange or service provider holds a certain amount of cryptocurrency. This evidence is usually generated by the exchange’s servers and can be independently verified by users. By providing this evidence, the exchange or service provider can demonstrate that it holds a certain amount of cryptocurrency and is not operating a fractional reserve system.
Mathematically, what this means is that if the entity (exchanges etc.) can prove that it has more assets (reserves held) than liability (customer deposits), then the entity can prove that it has enough assets (coins held in wallets) to cover all withdrawal claims.
Herein lies the paradox: if an entity makes everything transparent, then the world will trust you. But if you make it transparent, that also means exposing users’ financial information.
This is where cryptographic solutions come in, where you can prove that you are solvent without exposing user information.
This is where ZKP (zero-knowledge proof) comes in handy. (Paul from Pantera wrote a great article on this)
Essentially, you can demonstrate the proof without the need to reveal such information. Following Vitalik’s blog and zk-SNARKs, a class of zero-knowledge proof, properties of succinctness and non-interactivity (will dive into this more later) among prover and verifier, we will explore how this can be useful below.
ZK-SNARK
ZK-SNARK is made up of two parts: (1) ZK (zero-knowledge) and (2) SNARK (Succinct Non-Interactive Argument of Knowledge).
Let’s deconstruct below.
What is SNARK (Succinct Non-Interactive Argument of Knowledge)?
To understand the concept, we first need to know what an argument system is.
Argument System
An argument system is a system with two parties (prover and verifier) where the prover sends an argument to the verifier to be verified (such as verifying true or false).
As you can imagine, there are various potential concerns and considerations when implementing a such system.
Succinctness
First, the proof needs to be short and can be efficiently verified. This is needed because if the proof takes considerable floating point operations to be verified, it will render the entire system expensive to operate. This gives rise to the need for “succinctness”.
Non-Interactive
Second, there are various ways to achieve such proof. One of the methods is to have an interactive system where the prover and the verifier communicate back and forth in order to verify the proof. Practically, however, this will introduce exponentially more network traffic while bandwidth is limited. Thus, in order to make this solution efficient on a distributed system level, we also need to create a “non-interactive” prover-verifier system where only one round of communication is needed.
Where does ZK come in?
To drill down deeper, the equation for the prover and verifier system is that:
Simply put, the hashing circuit (a combination of sets of arithmetic operations of the given set of variables — see below) will return `0` if the hashed function returns a certain hash (h) for a given message (m).
Given the above, if you know the hash, then you would know the message. This message can be certain sets of data that you may not otherwise want to reveal (customer financial information).
In order to provide an additional layer of privacy and not reveal sensitive information, we add zero-knowledge proof so that we can prove the existence of such a message without revealing the message itself.
Final Note
We tend to believe that by solving and deconstructing a practical problem, we may be able to find a way to solve such problem through physical implementation.
In this case, we are defining what trust means in the context of the crypto financial system. We do this by first understanding the two sides of the problem and going one step further:
- Crypto industry: Why certain exchanges failed (People problem — dishonesty)
- Consumers: How is the public feeling about the space (Crypto is full of scams)
- Direction: How can the crypto financial system convey trust (Come up with a systematic solution)
Thus, keep iterating.
