mobileRumblefishLogo
Menu
desktopRumblefishLogo
Services
Products
Case studies
Careers
Resources
About us
The Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 1

The Current State of Knowledge About Zero Knowledge. Comprehensive Private Token Overview - Part 1

Mon, Jan 15, 20248 min read

Category: Code Stories

This blog post is the first of the three-part series regarding Zero Knowledge and Private Tokens. We’re going to take a deep dive into the history, evolution, and what lies ahead for Private Tokens. Today, I’m going to take you through the Blockchain Trilemma, the different approaches to on-chain user balance tracking, and more. Ready to dive in? Let’s get started! 

Part 1: Blockchain’s New Hope

Alright, so you’ve come across the term “blockchain” and wondered if it automatically guarantees privacy. Perhaps you've engaged in transactions and found yourself puzzled by the myriad of hashes and private/public keys. Ever wished it were as straightforward as typing in your name and sending tokens? Alternatively, you might be well-versed in blockchain tech but haven't delved into the realms of privacy, anonymity, and pseudonymity. If any of these scenarios resonate with you, grab a generous cup of coffee, find a comfortable seat, and let's embark on a journey through the expansive universe of blockchain!

Who is the Batman?

Anonymity is likely one of the buzzwords that pop up when people discuss blockchain. However, we need to recognize that it's not as simple as equating blockchain with anonymity. Why? Because while some blockchains offer the possibility of true anonymity, others do not.

Have you ever heard of Satoshi Nakamoto? That's the alias of the inventor of Bitcoin. We know his nickname and have a fair idea of his wallet addresses and some transactions, yet his real identity remains elusive (and probably always will). Think of him as Batman – everyone knows what he does and how he looks, but nobody knows his real face. This is pseudonymity. 
On the other hand, anonymity means your identity is concealed, and your actions can't be traced back to you or your address. However, this doesn't imply that transaction details are impossible to unveil. When the data of a transaction is entirely concealed, we call it a private transaction. Why might someone need it? Well, it can be a huge advantage for people who care about their digital privacy or for companies dealing with sensitive private data. And many many more. So privacy is gonna be the main topic of this series of articles, in which we’ll look at how it can be implemented and the pros and cons of different approaches.

Public, private, or permissioned?

Let's circle back to the blockchain. Imagine it as a decentralized public ledger capable of storing various types of data. So, how does a public ledger offer any privacy? The answer lies in cryptography — specifically, the mathematical underpinnings of this technology. Don't worry; we won't delve (too) deeply into concepts like zero-knowledge proofs (ZK), secure multi-party computation (MPC), or fully homomorphic encryption (FHE) this time. Instead, we'll provide an overview to grasp the context and understand the numerous approaches to blockchain architecture and its concepts.

Returning to the privacy dilemma for a moment, it's crucial to recognize that blockchain isn't inherently a private ledger by default. The widely known ones, such as Bitcoin or Ethereum, are indeed public, allowing anyone to join and participate in their core activities. Simultaneously, it's possible to establish a decentralized ledger (aka blockchain) controlled by a single entity (operator) that restricts access to the network, permitting only selected and verified participants to create it. This is referred to as a private blockchain.

You might wonder how this differs from a centralized database (an excellent question!). The key lies in immutability and digital signatures! Blockchains ensure that once data is recorded, it becomes practically impossible to change (well, almost, as explained in my previous post about Upgradeability). Just to let you know, there’s also a mix of public and private concepts named permissioned (in some cases called “consortium” or “federated”), which is public but can allocate specific permissions to a specific user.

Gotta catch ’em all! Security, Decentralization, Scalability - The Blockchain Trilemma

Why do we find ourselves in the position of having to choose the best fit for our needs among private, public, or permissioned blockchains? Can't we simply create and standardize a "Plug and Play blockchain"? It sounds fantastic, but it’s akin to facing the Blockchain Trilemma. Numerous articles, videos, and discussions delve into this theme, so here, I'll briefly sum it up to ensure you're familiar with the concept before we move forward. 
The Blockchain Trilemma, as articulated by Vitalik Buterin, posits that a blockchain can deliver only two out of three essential benefits: security, decentralization, and scalability.

The Blockchain Trilemma, as articulated by Vitalik Buterin, posits that a blockchain can deliver only two out of three essential benefits: security, decentralization, and scalability.

The Blockchain Trilemma
The Blockchain Trilemma

“Always two there are. No more. No less.”

Perhaps Master Yoda wasn't talking about blockchains, but we can certainly agree that, currently, two of the most significant blockchains with fundamental differences are Bitcoin (BTC) and Ethereum (ETH). In this discussion, I'll concentrate on one of many distinctions crucial to comprehending diverse approaches to privacy and anonymous transactions—specifically, the tracking of users' balances.

They say a picture is worth a thousand words. Indeed, let's start by examining the diagram below.

Now, let's take a guess at which one describes BTC and ETH. Alternatively, we can delve into the workings of these two.

The UTXO (Unspent Transaction Output) model serves as a foundational concept for the BTC network and was chosen for various reasons. It can be compared to cash transactions, where each UTXO is akin to a paper bill. For instance, if you need to pay $10 but only have a $20 bill, you hand over the $20, with $10 going to the recipient and $10 returned to you as a change. Each bill can be represented as a separate UTXO. Later, if you want to pay, say, $30, you would take $10 and $20 bills (two separate UTXOs) and create a single transaction (a single UTXO worth $30). In terms of the blockchain, the Bitcoin protocol doesn't track users' balances. Instead, each UTXO is attributed to a specific address. The protocol doesn't create your account with an updated balance but checks all your UTXOs and displays a summarized amount. Each Bitcoin node maintains a list of all UTXOs and checks their usability (whether they have already been spent).

Sticking with this real-life analogy, we can think of the Account Model used by ETH as a banking system, where every asset is represented by the balance within accounts. Each transaction recorded by the blockchain alters the system state, meaning that every node on the network must track and store all account balances with each new block added to the chain. For example, if Bob wants to pay Alice $20, his balance is decreased, and Alice's is increased by $20. To prevent a Double-Spending Attack (or, in ETH terms, a Replay Attack), each transaction has its own nonce—a number that can be used only once.

When it comes to privacy, both the UTXO and Account Models come with their respective pros and cons.

The UTXO model introduces a bit more complexity in linking transactions due to the ability to change addresses with each new one. A newly created address lacks an owner, making it less straightforward to trace connections between UTXOs and, consequently, correlate them to a single use.

On the other hand, the Account-based model doesn't offer such flexibility. Each address's state is meticulously tracked. However, it comes with a "built-in mixer", adding a layer of complexity to tracing the flow of money. If an account receives funds from various sources with numerous transactions, the entire amount is consolidated as the account's balance. When a new payment is recorded, it becomes challenging to pinpoint the exact coin that was used for that transaction.

It's important to note that this is a simplified overview, and we're not diving into the technical possibilities or "corner cases" at this point.

Yes, we can mix!

As mentioned earlier, one of the significant drawbacks of the UTXO Model is its relative difficulty in implementing multi-assets and smart contracts (or any kind of programs executed on-chain). Nevertheless, there are already ideas circulating on how to enhance the UTXO and make it more "programmable." This evolution can be observed in blockchains like Cardano or Nervos, which have implemented the Extended UTXO (EUTXO) models. These models might be considered even more flexible and developer-friendly than the Account-Based Model.

Without delving too deep into EUTXO (which is undoubtedly substantial enough for a separate article), we can simplify and assume that EUTXO extends the "basic" UTXO in two significant ways:

  • Uses scripts as logic to determine whether UTXO can be spent or not,
  • Allows the sending of (almost) any kind of data, not just address and value.

This is what distinguishes EUTXO from the Account-Based Model—scripts and data are used to alter the blockchain state.

That wraps it up for now and concludes the first part of my series. Today, we've laid the groundwork for Part 2, where I'll dive deeper into the realms of zero-knowledge proofs and private tokens. More to come next week - stay tuned!

Oskar Karcz
Oskar Karcz

Blockchain Developer at Rumble Fish

Categories
Follow Us
AnimatedLogoTextImageAnimatedLogoFishesImage
RUMBLEFISH POLAND SP Z O.O.Filipa Eisenberga 11/3 31-523 Kraków, Polska
NIP: 6772425725REGON: 368368380KRS: 0000696628
P: +48 601 265 364E: hello@rumblefish.dev
Copyright © 2024 Rumblefish