It is well known in the crypto market that scalability remains an unresolved roadblock to mass market adoption. Bitcoin and Ethereum, the two largest cryptoassets by market capitalization, max at around 7 transactions per second (tps) and 15 tps, respectively. To put this into context, individuals often cite the Visa network’s ability to process over 24,000 tps as a benchmark. CryptoKitties, a decentralized app where you can collect and trade digital kitties, nearly crashed Ethereum at the end of 2017 because of the congestion in processing trades. Without scalability, blockchains cannot function.
So what’s preventing blockchains from becoming as scalable as Visa’s network? Their decentralized nature.
Bitcoin and Ethereum are trustless because there are thousands of independent nodes across the world, run by independent companies and individuals, that maintain the security of the network. The more nodes there are, the more difficult it is for one node/person/nation/enterprise to attack the network. However, the more nodes there are, the more servers decisions are processed through, and thus the longer it takes to agree on a decision. A direct democracy is a good analogy here — how long would it take to pass a bill if every American citizen had to vote on every bill proposed as a new law?
Vitalik Buterin, co-founder of Ethereum, has coined this major problem the “scalability trilemma”: how can blockchains be scalable, secure, AND decentralized? Solving this trilemma remains the foremost objective in the industry today. If we cannot find solutions, adoption will never take off, and the complex challenges our industry addresses like non-sovereign money, individual data ownership, or banking the unbanked, may never be solved.
For now, there are a few core ideas behind solving the scalability trilemma:
- Replace the “direct democracy” approach blockchains use for governance with a representative democracy. The independent nodes all over the world elect a subset of nodes to manage the network. This way, decisions only have to pass through the delegates and can be made much faster. Three of the largest blockchains by market cap, EOS, Tron, and Tezos use delegated governance. Critics of delegated blockchains argue that with fewer machines, the network will become less secure, and furthermore, these “elections” are subject to manipulation, increasing the potential for corruption.
- Use a smaller number of trusted nodes run by corporations that have reputation at stake
- Maintain the fully decentralized (direct democracy) approach; instead, rely on technological improvements to increase the efficiency of the communication between the nodes in both time and space.
- Since not all transactions need such a high level of security, we can move/validate those with lower security requirements off-chain or to side-chains.
The last two options are complex. There are dozens of companies that are trying to solve this at the protocol layer using technology like sharding or complex calculus. There are many others tackling scalability via off-chain and side-chain solutions such as payment channels (lightning network, raiden) and other state channels, plasma. None of these are yet successfully operational at scale. You can time stamp the industry as being in the midst of a “scalability race.”
But what’s this have to do with Privacy?
Many crypto enthusiasts were originally attracted to Bitcoin because they believed it was anonymous. This is not true; contrary to popular belief, Bitcoin is far from anonymous. While real-world identities aren’t revealed, when users engage in a Bitcoin transaction, their public keys (public address), and transaction amounts are broadcasted to the public ledger. Anyone who has obtained a record of the blockchain over time can easily visit these users’ wallet addresses to see how much Bitcoin they own. Furthermore, once someone transacts with a counterparty he/she learns one of the counterparty’s public keys, and thereafter can trace the holdings tied to that public key. In fact, law enforcement has previously used end-users’ misperception of Bitcoin’s transparency to its advantage. Kathryn Haun, who is a General Partner at Andreessen Horowitz, previously led a Ted Talk on how the US Government used full-nodes on Bitcoin to trace $13.4M to Ross Ulbricht, the mastermind behind the first modern darknet market, Silk Road.
Nevertheless, there are multiple blockchains that have been engineered to be private. The major ones, based on their technical proficiency and the market cap of their associated cryptocurrencies, are Monero and Zcash. In addition, two new privacy coins, Grin and Beam, launched in January 2019 and are generating a lot of recent buzz in the industry. Privacy research continues to be at the forefront of the crypto space, as we’ve seen with the most recent Zether whitepaper, published in late February 2019 as a collaboration between the senior research teams in applied cryptography from Stanford University and Visa.
The purpose of these blockchains is self-explanatory: you can buy/sell/trade value and record the transaction on the blockchain, anonymously. Many view privacy coins as technology that supports the dark web; however, privacy is important for all users if crypto payments are to become mainstream — do you want your coworkers to know how much you spent on your girlfriend’s birthday present? These blockchains are working on protocols that fundamentally protect people’s personal information but also can be audited/examined by law enforcement if nefarious activity is suspected.
So, what does privacy have to do with the scalability race? Think about it this way — when you don’t tell everyone, everything, you theoretically can save time and space. Capitalizing on this interesting axiom, blockchain developers have been working hard to implement “zero-knowledge” proofs, which are protocols within the blockchain code that allow independent nodes to verify transactions in a block without identifying the participants involved or the inputs and outputs of the transactions. There are ways, using math, to make this possible, which is an amazing and potentially game-changing concept. Thus privacy blockchains and scalability progress are intimately linked.
We start with one of the oldest and largest privacy coins by market capitalization — Monero.
Monero is the oldest major privacy coin. It was created in 2014 through a hard-fork of the Bytecoin protocol. Monero, by design of the protocol, has mandatory anonymization. The protocol relies on three methods to accomplish this (and a fourth on the way):
1. Ring Signatures
Ring Signatures protect the anonymity of the sender (from everyone but the receiver). Generally speaking, when a sender initiates a transaction with a recipient in a blockchain network, the sender digitally signs, with its private key, the value it is sending to prove to the recipient they agree to the value they’re transferring. This is the technical equivalent to signatures we provide on documents today when we’re agreeing to a transaction i.e. signing the check. The receiver uses the public key of the sender to unpack the digital signature from the sender and confirm, based on what the unpacked digital signature says, that the sender intended to send what was sent. Most blockchains today are multi-signature protocols, meaning multiple entities need to sign the transaction on behalf of the sender before it is submitted to the receiver. The receiver then can use the public keys from all of the entities that signed the transaction to decrypt the digital signature and confirm its accuracy.
Ring signatures are a specific type of multi-signature where at least six decoy parties, who each hold the same amount of transacted Monero in their wallets, are randomly selected to sign a transaction in addition to the true sender. You can verify the validity of the transaction by using the public keys of the parties, but you cannot figure out which member sent the funds, and which are decoy co-signers. As Monero’s sponsored website puts it: “In a ‘ring’ of possible signers, all ring members are equal and valid. There is no way an outside observer can tell which of the possible signers in a signature group belongs to your account.”
However, Monero initially had issues guaranteeing anonymity with ring signatures because observers, who had access to the public keys of the random accounts chosen, could explore the transaction history of each of the public keys and eliminate the public keys that were inactive — meaning they hadn’t transacted Monero in a while. As it turned out, the account with either the most recent or most active wallet was usually the sender.
Additionally, adding at least six decoy signatures to each transaction significantly increases the size of a transaction and ultimately the Monero blockchain. Because full-nodes have to scan the entire blockchain to validate transactions, the larger the size of the blockchain, the longer it will take to validate transactions, and the more expensive it will be for nodes to scan the blockchain.⁷
RingCT, adopted by Monero in January 2017, anonymizes the amount sent between the sender and receiver. RingCT implements the Confidential Transactions algorithm developed by Gregory Maxwell, a type of “zero-knowledge” proof which allows for the amount transferred to be completely obfuscated to everyone outside of the sender and receiver. The implementation of Confidential Transactions is a reflection of the progress the industry has made with implementing zero-knowledge proofs in the last two years.
Here’s how the algorithm works: before the transaction is submitted to the blockchain, the sender and receiver each choose their own “blinding factor”. A blinding factor is a randomized string of letters and numbers that is multiplied by the value being transacted to obscure the network from knowing how much is really being transferred. Multiplying the blinding factor by the value being transferred produces a new public key called a “Pedersen Commitment”. The sender and receiver each create their own Pedersen Commitment and subtract the receiver’s Pedersen Commitment from the sender’s (Output — Input). When the transaction is published to the blockchain, validating nodes just see the resulting Pedersen Commitment.
Because the validators do not know the random blinding factors of the sender and receiver, there’s no way for them to unwind the resulting Pedersen Commitment and determine the value transferred. But the validators do not need to unwind anything in order to approve the transaction. Here’s the zero-knowledge proof: the only component that differs between the Pedersen Commitment of the sender and that of the receiver is the difference in value of their blinding factors. So as long as the receiver’s Pedersen Commitment — the sender’s Pedersen Commitment equals the difference in their blinding factors, the validating nodes can approve the transaction and post it to the next block.
You may ask — how can the validators be sure the resulting Pedersen Commitment equals the difference in their blinding factors? To test this, before the validators approve the transaction they could have the involved parties redo their transaction with dummy blinding factors supplied by the validators and see if the resulting Pedersen Commitment is what the validators anticipate. Ultimately, there are many ways the protocol can test for the “soundness” of a zero-knowledge proof without breaking with zero-knowledge principle. These are called rangeproofs, and they are a series of proofs that prove a blinding factor lies within a certain interval or “range” of known numbers. A common rangeproof is to prove that the value transacted is non-negative, as transferring negative values would allow the sender to create value out of thin air. Confidential Transactions require that each transaction contains a rangeproof(s), and the rangeproofs are actually included in the block with the transaction data. For those interested, you can learn more about Monero’s particular rangeproofs here.
In addition, by obscuring transaction values the adoption of RingCT minimized the vulnerability in detecting the true sender in Ring Signatures because it eliminated the requirement that each of the decoys have to possess the value being transferred, thereby massively increasing the decoy pool.
Although zero-knowledge proofs might be the holy grail of secure verification in decentralized systems, the first implementations have been both computationally intensive and expensive. This can be attributed to the rangeproofs, which account for the vast majority of data in blocks that use them. Therefore, in October 2018, Monero hard-forked its protocol and reconstructed Confidential Transactions into a bulletproof, a much more efficient zero-knowledge proof standard. Under the original zero-knowledge proof standard for Confidential Transactions, each transaction size in a block scaled linearly (1 output = 7kB, 2 outputs = 13kB). Under bulletproofs, transaction sizes scale logarithmically instead (ex: 1 output = 2kB, 2 outputs = 2.5kB). According to Monero, this represents an 80% reduction in transaction size. Therefore, the integration of bulletproof standards into zero-knowledge algorithms has the potential to give the Monero blockchain sustainability.
3. Stealth Addresses
Stealth Addresses protect the anonymity of the receiver (from everyone but the sender). Before completing the transaction, the sender creates a new, one-time public address for the receiver by multiplying its private address by the public address of the receiver, thereby creating a stealth address. This stealth address is what the receiver submits to the block when the transaction is pending.
Stealth addresses protect the anonymity of both the sender and the receiver:
- Because a hashed output address doesn’t reveal anything about its inputs, the receiver doesn’t learn the sender’s private key through this process.
- Because none of the validators know the sender’s private key, they cannot establish a connection between the receiver’s public key and its stealth address.
- Because a new stealth address is created for each transaction, this limits each sender’s ability to track the activity of the receiver just to their transaction.
In order to understand Kovri, it’s important to know that there are two layers to blockchain privacy. The first, which Ring Signatures, RingCT, and Stealth Addresses attempt to protect, is validation privacy: the network can verify the transaction without exposing the personal/private details of the involved parties. The second is transmission privacy.
In order to understand transmission privacy, we need to briefly walk through how data transmission works on the Internet. Data transfer on the Internet, whether via a blockchain or other, fundamentally works in the same way: the data is originated and sent from a computer, known as the “client” node. The client node has a public address associated with it, which represents its location within the Internet, known as an IP address. Whether we realize it or not, the data sent and received online is always triggered by a command from the client node via an Internet browser, such as “send me to ESPN.com,” or “send this message to that e-mail address” or “send 3 BTC to Alice.”
Based on TCP/IP, the communication protocol for the Internet, the sender’s command tells its client node what the intended destination node is supposed to be for the data. Almost always, unless the client and destination nodes are on the same local network, the client node only knows the destination’s domain name, such as espn.com or an e-mail address. In other words, the sender doesn’t know the IP address of the receiver. As a result, the data travels through the Internet being forwarded from the client node through a pathway of nodes, known as “relay” nodes, looking for a DNS server that contains the domain name in its database and its associated IP address.
Here’s a key point to understand: the data itself isn’t traveling aimlessly looking for the right DNS server. If that were the case, the data would pass through and be exposed to a bunch of unnecessary nodes. Instead, the shortest path between the senders address and unknown receivers address is solved, like a puzzle, using Dijkstra’s algorithm. Once the shortest path is determined, the data passes through the relay nodes along that path. Therefore, unnecessary nodes do not touch the data.
Here are additional consequences of this setup:
- Because Dijkstra’s algorithm determines the transmission route before the data is transferred, each node only knows the previous node and the next node in the transmission pathway. The only computer that knows the sending IP address is the sender, and the only computer that knows the receiving IP addresses is the destination computer.
- The DNS server is queried for the IP address of the destination computer, but because Dijkstra’s algorithm computes before the data is transferred, it learns nothing about the information/value being transferred.
- The data that’s being transferred does not contain information on the sender and receiver. So again, relay nodes learn nothing about the sender and receiver.
- The Internet and TCP/IP protocol use domain names for navigation rather than IP addresses because this adds in a critical layer of obfuscation.
So — taking all this into consideration, where’s the vulnerability? Our description may have made TCP/IP appear fortified, but there are actually multiple ways to “cyber attack” via the Internet. There’s an entire industry (Cybersecurity) dedicated to combating this pursuit. Generally speaking, the first type of attack are destructive attacks — many of these, such as DDos, overwhelm and take out the functionality of a targeted client. The second are spying attacks — where attackers can access the sender, receiver and data being transferred.
So how can blockchain nodes avoid the range of possible cyber attacks? Well, guaranteed avoidance isn’t possible unless nodes remain offline, because when you interact with other nodes you assume the risk the counterparty is infected with a virus, that upon interaction, could harm your computer. This, again, is merely how the Internet works because it’s empirically peer-to-peer / node-to-node. However, if the attack isn’t coming from your counterparty but rather a third-party, there is a proposed solution for how to avoid attacks: obfuscating either your location or your transmission pathway.
Privacy, the form of cryptography, strikes again. One of the preeminent proposals behind transmission security are anonymous P2P communication systems. Heard of Tor? Tor, or The Onion Router, was the first commercialized anonymous P2P communication system, developed in the mid-1990’s by the US Navy to protect US intelligence communications online. The purpose of Tor is to enable anonymous transmission of data on the Internet. Nodes on the Tor network essentially have downloaded the Tor software that allows them to decrypt encrypted data transmissions. The Tor network consists of the user/client, internal relay node and exit nodes, which are the last node in transmission before the data exits out of the Tor network and is sent to the receiver, who is likely outside of the Tor “bubble.”
Additionally and also as popular, there’s the Invisible Internet Project (I2P), which takes anonymity one step further. I2P, initially released in 2003, is an encrypted Internet inside of the Internet; sender and receivers are apart of the I2P network, and the protected data never leaves the bubble. Because of this, some refer to I2P as the true darknet. Both I2P and Tor are free and open-source software. You can learn more about how Tor and I2P work and their similarities and differences as P2P encryption networks here.
A Monero development team, led by core Monero developer “Anonimal” has been working on an integration of I2P for Monero named Kovri. Simply put, I2P is programmed in Java and Kovri was proposed as an enhanced, C++implementation. Kovri currently is not live and updates from Anonimal have been few and far between. On December 25, 2018, Anonimal released a white paper on Sekreta, which could be an updated version of Kovri and references Kovri’s I2P protocol throughout its analysis. All in all, the intention of Kovri / Sekreta is to couple transmission privacy with the more popularly addressed validation privacy. We will provide updates if there is any announced progress on Monero’s I2P solution.
In review, Monero has mandatory anonymization and utilizes a combination of zero-knowledge algorithms and community-based signature mixing to preserve users’ privacy. Monero developers are working on an interesting side project to secure transmission privacy, but this project is still under development.
This is an excerpt from a report that was originally published by Wave Financial.