Identity and the Dangers of Hacking

Why is it important for users to have ownership of their data? Large companies in the technology and finance space have not been great stewards of data. They have repeatedly been breached, hacked, and otherwise compromised. In many cases they have then attempted to downplay or conceal these breaches, though they have often been caught (and fined) later. For example:

Blockchain technology is promising in that it has the ability to disintermediate various industries, many perhaps quite quickly. Some experimentation has already begun. Industries including technology, finance, jobs, and gaming are ripe for disruption. The technical “scaffolding” is being built today for users to have more control over their data.

The ultimate realization of this idea is the concept of self-sovereign identity, where individuals generate their own unique identifiers and store and control access to their own personal information, using public/private key pairs. The idea of an identity that is owned by a user instead of large companies and government bureaucracies is something blockchain developers are enthusiastic about, and it could remove the danger of future hacks and thefts that put people’s identities at risk.

In order to use a number of DeFi services, users must become familiar with wallets. Fortunately, a number of good options are available today. MetaMask is a software wallet that currently works inside the Chrome, Firefox, and Opera browsers. It is also available for Brave, a new type of browser discussed later in this chapter. Hardware wallets like Ledger are another alternative, and Coinbase also offers support for those who don’t want to concern themselves with key storage.

Private Keys

The MetaMask and Ledger wallets require users to know and carefully store their private keys. The loss of a password, or seed—a list of words that store all the information needed to recover a wallet—can equal the loss of a private key. Because of this, new services that help users maintain identity while securing private keys are important. Coinbase already does this for cryptocurrency wallets. Identification services like Keybase and Blockstack make it easier for users to maintain private keys for different types of Web 3.0 services, covered later in this chapter.

Naming Services

Public keys are much more difficult to use than email addresses, usernames, or other identifiers, yet they are very important to decentralized services. Figure 7-1 shows examples of public and private keys. The QR codes are representations of the keys.

Figure 7-1. Public and private keys

Naming services allow users to have names that are much more easily read and typed than complex public keys are. An example is the Ethereum Naming Service, which allows people to use a <username>.eth naming convention that translates to a public key. The drawback is that using these names can allow analytics to track transactions on the blockchain, which risks revealing identity information.

Smart contracts are essential to the DeFi model. Many cryptocurrencies are valuable because of the existence of a fixed supply of assets in circulation. However, many DeFi tokens have an elastic supply to make them inflationary or deflationary, depending on the design of the system. This is where some new terminology needs to be defined:

Minting

Used to increase a cryptocurrency supply, minting involves the creation of new assets. This is done with the creation of new blocks as rewards are generated for stakers, or users who pool assets for incentives. Minting must be properly controlled in order to limit inflation via some system of governance. Otherwise, the value of a cryptocurrency may fall in relation to other assets, diminishing its purchasing power and store of value properties. Minting is algorithmically fixed, or relegated to authorities within a system.

Burning

Used to decrease a cryptocurrency supply, burning involves the destruction of assets. This destruction is done by system authorities. By reducing circulation and lessening supply, this can cause the price of a cryptocurrency to go up. However, the asset could become deflationary via this process—while the value goes up, prices of other assets may go down. Burning could be a one-time event, or a staggered event triggered by revenue/earnings. Burning is also a way to distribute profits back to token holders by reducing the supply in hopes demand and prices rise.

Wrapped tokens

The Ethereum platform was not designed with the ERC-20 standard in mind. Neither were Bitcoin or any other cryptocurrencies outside of the Ethereum ecosystem. Because of users wanting to trade various cryptocurrencies with ERC-20s in smart contracts, wrapped tokens have become a solution. The original asset is “wrapped,” meaning provably held on-chain as collateral. A smart contract facilitates the processes of depositing (minting) and withdrawing (burning) for these ERC-20 representatives of their external cryptocurrency counterparts. Some level of trust is required to assure that the external tokens remain in custody for the holder of the wrapped token balance. Typically, a multisignature scheme is implemented among disinterested custodians who mutually sign off on withdrawal requests.

DAOs

Decentralized autonomous organizations (DAOs) are projects organized via code, mostly through Ethereum smart contracts. Not controlled by a central authority, DAOs have token holders to provide governance. Because DAOs utilize blockchain-based smart contracts, there are transparent records of transactions and the rules governing a DAO. Although their legal and regulatory status isn’t clear, DAOs have already been used for finance, gaming, and social media.

Oracles

Because blockchains don’t interface well with data sources, such as relational databases, oracles are required to provide outside information. Real-world events that are recorded in centralized databases are still needed for these systems to function, and oracles serve that purpose. Oracles bring off-chain data on-chain, as illustrated in Figure 7-3.

Figure 7-3. How oracles interact with blockchains

Stablecoins

As blockchain-based assets that peg to the US dollar and other fiat currencies, stablecoins underpin services that don’t require banking intermediaries. Many stablecoins do have some regulatory risk (discussed in Chapter 6). In addition, there are various levels of governance and centralization between different projects. Nevertheless, interesting experiments are being done with stablecoins. We’ll briefly look at a few of them here.

KYC and pseudonymity

As mentioned in the previous sections, although DAI does not require KYC information from users, TUSD and USDC do. Because of banking relationships, TUSD and USDC require users to provide personal information to redeem their stablecoins for fiat. However, inside the blockchain ecosystem, the stablecoins can be used pseudonymously, changing hands while leaving a blockchain record, as Figure 7-4 illustrates.

Figure 7-4. How stablecoins can be used pseudonymously

Although DAI is the most used stablecoin in DeFi applications, bank-backed solutions are competitors. The main difference is that TUSD and USDC are backed by fiat, whereas DAI is currently backed by cryptocurrencies.

There is a market for users who want to borrow fiat and keep crypto. DeFi loans generally have a very specific purpose. Many cryptocurrency holders don’t want to sell crypto, whether for speculative reasons, because they believe in the long-term value of cryptocurrency, or because they don’t want to pay taxes upon converting to fiat. They don’t want to give up their assets, and will pay for the privilege.

One way to accomplish this is to use a service such as Compound, one of the largest decentralized lending platforms today. Compound allows users to borrow against cryptocurrency holdings. The amount borrowed is overcollateralized, and issued in DAI. This DAI, because it is pegged to the dollar, can be sold on the market for fiat or used to invest in other cryptocurrencies.

Savings

DeFi savings involves users locking cryptocurrency, usually stablecoin, into a smart contract. The contract then provides a yield in the native cryptocurrency. The concept is similar to staking (discussed in Chapter 2), except there are no transactions being validated as a result of the cryptocurrency being locked up in a smart contract.

Maker has savings rates for DAI locked up in what is called a DAI Savings Rate (DSR) contract. The interest paid comes from the stability fees that vault owners pay to borrow DAI against cryptocurrencies like ETH. The rate is variable, determined by the MKR token holders. Unlike when borrowing DAI, there is no penalty to take out saved DAI or the interest paid. Compound also has a DeFi savings program.

In DeFi, derivatives are used as collateral for synthetic assets. For example, you might use ETH to get an asset like BTC or gold on the ERC-20 network. Exchanges are emerging that offer a number of derivative assets, enabling traders to frictionlessly move between these assets in ways that were not possible in the past. Previously, this would have required access to several different trading markets.

DEXes are designed to work in a very different way than a centralized exchange. The goal of a DEX is that it can provide users with 100% functionality without depending on one centralized authority to power any part of the exchange. This can lead to a more transparent, secure, and trustworthy service that allows users to maintain custody of their funds at all times. The downside of a DEX is that its speed and scalability are limited by the blockchain it runs on. This is because users maintain custody of funds, which adds complexity to the overall experience.

Infrastructure

In a centralized exchange, all of the infrastructure is controlled by a single entity, usually a company, and is delivered to the user through a website. In contrast, all parts of the Uniswap DEX are run by the community, as illustrated in Figure 7-5.

Figure 7-5. High-level view of infrastructure differences between centralized exchanges and DEXes

Table 7-1 compares the frontend code for a centralized and decentralized exchange (in this case, Uniswap).

Table 7-1. Frontend differences between centralized exchanges and Uniswap

Type	Centralized exchange	Uniswap
Distribution & transparency	The frontend code is kept private by the exchange and runs on infrastructure the exchange controls.	The frontend code is shared in the Uniswap GitHub repository.
Control	The frontend runs on infrastructure the exchange and its hosting provider control.	Anyone in the community can launch their own website that interacts with the Uniswap DEX.
Functionality	The frontend receives data from the backend, for example to get the exchange rate for the market USD/ETH. The frontend code also sends instructions to the backend, for example to execute a trade.	The frontend code only receives data from the DEX smart contract. It does not send instructions to the backend. Instead, the user sends instructions to the smart contract directly from their client device using an Ethereum wallet like MetaMask. The frontend code makes this process more user-friendly by setting up the transaction for the user.
Transaction authorization	The transaction authorization is performed in the frontend code, usually with a cookie or an access token stored in the browser.	The user authorizes the transaction by generating a transaction signature using their private key, stored in MetaMask. MetaMask then pushes the transaction to the smart contract.

Figure 7-6 is a screenshot of a user executing a trade on Uniswap. Note that the transaction authorization occurs in MetaMask, not in the frontend code.

Figure 7-6. A user executing a trade on Uniswap

Table 7-2 outlines the differences between a centralized exchange and a DEX with regard to the backend and database.

Table 7-2. Backend/database differences between centralized exchanges and Uniswap

Type	Centralized exchange	Uniswap
Distribution & transparency	The backend and database are kept private by the exchange. The public is unable to audit the exchange’s code.	The backend logic runs in a smart contract. The code in Uniswap smart contracts can be viewed publicly, so potential users can audit the code before using the DEX. All Uniswap transactions are recorded on the Ethereum blockchain, which is also publicly viewable.
Control	The backend runs on infrastructure the exchange and its hosting provider control. The exchange can make changes to the backend server or database at any time. In addition, the exchange or hosting provider can shut down the backend or database at any time.	Uniswap smart contracts and transactions are powered by and recorded by thousands of miners. The smart contracts and transactions are immutable and can never be changed. The only way to shut down the smart contract or stop transactions from completing is by shutting down the Ethereum network.
Authorizing code execution	Before executing any business logic, the backend authorizes API requests using security standards like JWT or OAuth.	Smart contract code is run on the Ethereum Virtual Machine (EVM). The smart contract runs on the node of the miner producing the block and everyone in the network running a full node validating the chain.

Figure 7-7 shows part of the Uniswap V1 Exchange Template smart contract, viewable on the blockchain.

Figure 7-7. One of Uniswap’s smart contracts, publicly viewable on the Ethereum blockchain

Token listing

When the makers of a token want a centralized exchange to list their token, there is often a long delay while both parties attempt to negotiate the terms of this business transaction. Often, the token company has to pay a listing fee and provide legal documents and legal opinions to reduce the exchange’s liability.

Since a DEX is not controlled by anyone, the makers of a token can list their token on their own—no permission required.

If someone wants to list an ERC-20 token on Uniswap, all they have to do is call the createExchange method in the Uniswap Token Factory smart contract (0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95), shown in Figure 7-8.

Figure 7-8. Uniswap Token Factory method that allows anyone to list an ERC-20 token on the Uniswap DEX

As an argument, they need to pass the address of the ERC-20 token smart contract. For example, if you wanted to add the SAI ERC-20 token (0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359), you would execute the createExchange method and pass the following argument:

Argument name	Value
token	0x89d24A6b4CcB1B6fAA2625fE562bDD9a23260359

The Uniswap Token Factory would then generate a new smart contract that allows anyone to trade ETH for SAI and vice versa.

Custody and counterparty risk

Users of a centralized exchange have to deposit cryptocurrency to begin trading, and the exchange takes custody of their funds. Since the exchange controls users’ funds, there is exposure to counterparty risk. That is, if the exchange gets hacked or shuts down, there is a risk that its users’ funds may be lost.

When someone uses a DEX, the smart contracts manage deposits, withdrawals, trades, and maintaining custody of user funds. Before sending funds to the DEX, users can audit the smart contract code to know how their funds will be used.

Here are the important things to look for in the smart contract:

• What smart contract methods can move the user’s funds?

• Who can call those methods to move the user’s funds?

• Where can those funds be moved to?

To clarify how Uniswap manages user funds, we executed a small trade on the DEX and then audited the transaction, as shown in Figure 7-9.

Figure 7-9. Publicly viewable record of a method call to a Uniswap smart contract

As you can see, we traded 0.05 ETH for 8.34 SAI tokens, worth about $8 USD.

In the transaction record, the input data field contains this value:

0xf39b5b9b0000000000000000000000000000000000000000000000007349d8cdf224ded30000000
00000000000000000000000000000000000000000000000005e283df6

Breaking down the input data shows which smart contract function is called and the arguments passed.

The first 10 characters of the input data field specify the function being called. In this transaction, the first 10 characters are 0xf39b5b9b. Using an online directory, you can learn that the function being called is ethToTokenSwapInput(uint256,uint256). The remaining characters in the input data field are the values of the arguments passed into the function:

0000000000000000000000000000000000000000000000007349d8cdf224ded3

000000000000000000000000000000000000000000000000000000005e283df6

Auditing this transaction, we see that the following steps took place:

1. The transaction sent 0.05 ETH from our address (0x76e55ab64c5e2415a8a6375fef216977de7ea213) to the Uniswap SAI smart contract (0x09cabec1ead1c0ba254b09efb3ee13841712be14). Those funds will remain in the smart contract to be used as liquidity for future trades. It’s similar to a bank account: when a user puts funds in, they still own the funds and can pull them out at any time; however, while the funds are sitting there, the bank can use them too.

2. The transaction called the function ethToTokenSwapInput in the Uniswap SAI smart contract (0x09ca…be14) with these input values:

Argument name	Value
min_tokens	0000000000000000000000000000000000000000000000007349d8cdf224ded3
deadline	000000000000000000000000000000000000000000000000000000005e283df6

These arguments are in hex format because smart contracts are compiled into bytecode. Decoding them into human-readable values gives us this:

Argument name	Value	Type
min_tokens	8307409366703988435	uint256
deadline	1579695606	uint256

Note

When calling a smart contract, users must send values in hex as arguments. There are tools available online, such as Moesif’s binary encoder/decoder, to help create the input data to be sent with a transaction.

Let’s take a closer look at the ethToTokenSwapInput function defined in the Uniswap V1 Exchange Template smart contract mentioned earlier (Figure 7-10).

Figure 7-10. The ethToTokenSwapInput function from the Uniswap template code

Looking at the method definition, you can see that it calls another method, ethToTokenInput. As Figure 7-11 shows, this method is where the real logic of this transaction takes place.

Figure 7-11. Transaction logic

Line 128 in Figure 7-11 checks to make sure that the following are true:

• The deadline given is equal to or later than the timestamp of the block in which this transaction is being included.

• The amount of eth_sold is greater than 0.

• The number of min_tokens expected is greater than 0.

Line 129 gets the quantity of tokens that the smart contract is currently holding.

Line 130 gets the number of tokens that the user should receive in the trade. This is an important line because it shows how the exchange rate for the trade is calculated. It calls the function getInputPrice, which determines the exchange rate based on the ratio of ETH to SAI currently sitting in the smart contract.

Line 131 checks to make sure the value of tokens_bought is greater than or equal to the min_tokens value, which is the minimum number of tokens the user is willing to receive.

If all the previous checks were valid, line 132 is executed. This line transfers the tokens from the smart contract to the recipient’s address. More technically, it calls the method transfer in the SAI smart contract (0x89d2…0359) with the following arguments:

Argument name	Value	Type
dst	0x76e55ab64c5e2415a8a6375fef216977de7ea213	address
wad	8342650846452389346	uint

Line 133 broadcasts out to all listeners of the event TokenPurchase that this trade has been executed.

Finally, line 134 returns the value token_bought, which is how many tokens the user received.

Here are the input values passed to the ethToTokenInput method in our example transaction, resulting in the trade of 0.05 ETH for 8.34 SAI tokens:

Argument name	Value	Type	Description
eth_sold	50000000000000000	uit256(wei)a	msg.value is passed for this argument, which refers to the amount of ETH that was sent in the transaction (0.05 ETH). The type is uint256(wei), where 1 ETH = 1018 wei, so we multiply 0.05 by 1018.
min_tokens	8307409366703988435	uint256	This value was passed from the original transaction. It specifies the minimum number of tokens that we are willing to receive before executing the transaction.
deadline	1579695606	timestamp	This value was passed from the original transaction. It represents the latest possible date that we are OK with for executing the transaction.
buyer	0x76e55ab64c5e2415a 8a6375fef216977de7ea213	address	msg.sender was passed for this argument, which refers to the address that executed the transaction. That was our address.
recipient	0x76e55ab64c5e2415a 8a6375fef216977de7ea213	address	Same as previous.
a Wei is the smallest denomination of ether. 1 ether = 1,000,000,000,000,000,000 wei. When interacting with the Ethereum blockchain, numbers are in terms of wei.

Creating a Flash Loan Contract

Let’s look at an example of how to perform a flash loan. In this example we will do the following:

pragma solidity ^0.6.6;
// Import Aave flashloan code. By importing you are saving resources from
// having to write out this code.
import "https://github.com/aave/flashloan-
  box/blob/Remix/contracts/aave/FlashLoanReceiverBase.sol";
import "https://github.com/aave/flashloan-
  box/blob/Remix/contracts/aave/ILendingPoolAddressesProvider.sol";
import "https://github.com/aave/flashloan-
  box/blob/Remix/contracts/aave/ILendingPool.sol";

contract Flashloan is FlashLoanReceiverBase {

/**
The following constructor method is run when you create this flashloan smart
contract. Make sure to specify the address of the Aave LendingPoolAddressProvider
contract. This argument is different based on the environment you are working in.
Visit the Aave docs to get this address.
*/

    constructor(address _addressProvider) FlashLoanReceiverBase(_addressProvider) 
      public {}

    /**
    The following function is called by Aave to the flashloan contract after the
    contract has received the flash-loaned amount:
     */

    function executeOperation(
        address _reserve,
        uint256 _amount,
        uint256 _fee,
        bytes calldata _params
    )
        external
        override
    {
        require(_amount <= getBalanceInternal(address(this), _reserve), 
                "Invalid balance, was the flashloan successful?");

        // Your logic goes here.
        // !! Ensure that *this contract* has enough `_reserve` funds to
        // pay back the `_fee` !!
       
        uint totalDebt = _amount.add(_fee);
        transferFundsBackToPoolInternal(_reserve, totalDebt);
    }

    /**
    Call the following function when you want to execute a flash loan. The
    parameter _asset is the address of the token you want to borrow in the
    flash loan. In our example the token we will borrow is DAI.
    */

    function flashloan(address _asset) public onlyOwner {
        bytes memory data = "";
        uint amount = 1 ether;

        ILendingPool lendingPool = 
          ILendingPool(addressesProvider.getLendingPool());
        lendingPool.flashLoan(address(this), _asset, amount, data);
    }
}

Flash loans have also been used by bad actors to exploit vulnerabilities in DeFi platforms. A well-known example occurred on February 15, 2020, when an attacker used a flash loan to perform an oracle manipulation attack on the Fulcrum margin trading platform.

An oracle provides smart contracts with a trusted view of the outside world. For example, a DeFi smart contract will use an oracle to know what the BTC/USD exchange rate is. On the day of the attack, the Fulcrum platform was listening to multiple oracles for exchange rate data, including Kyber and Uniswap. One reason Fulcrum gathers exchange rate data from these DEXes is that it accesses their liquidity pools to provide margin trades for Fulcrum’s users.

0xb5c8bd9430b6cc87a0e2fe110ece6bf527fa4f170a4bc8cd032f768fc5219838

The transaction details can be viewed online. In total, 13 smart contract function calls were made.

In an exploit such as this, the attacking flash loan contract borrows, trades, and repays wrapped tokens. These are ERC-20 tokens that represent the value of a different cryptocurrency. For example, 1 wBTC is a wrapped bitcoin that represents 1 BTC and in theory is worth 1 BTC, but is in the form of an ERC-20 token.

We can break down the process of the attack into five distinct steps, which are illustrated in Figure 7-16.

Figure 7-16. Walkthrough of the Fulcrum attack

The steps can be summarized as follows:

1. Borrow: The attacking flash loan contract borrows 10,000 ETH ($2.81M USD) from the dYdX decentralized trading platform. This action is only valid if it repays the loan plus a fee at the end of this Ethereum transaction.

2. Hoard: It then borrows 112 wBTC ($1.15M USD) from DeFi lending platform Compound. To secure these funds, it provides 5,500 ETH ($1.5M USD) as collateral. The 112 wBTC will later be dumped onto another market in order to manipulate the oracle rate.

3. Manipulate oracle rate: Next, it deposits 1,300 ETH onto the Fulcrum margin trading platform and opens a short trading position, which is a bet the price will fall, on the wETH/wBTC market with 5x leverage. This short position creates a domino effect. In order for Fulcrum to service the short position, it swaps 5,637 ETH ($1.58M USD) for 51.34 wBTC ($525,000 USD) from Kyber. Kyber sources the 51.34 wBTC from Uniswap. Significant slippage—when a price moves substantially because of a lack of sufficient liquidity—occurs when Kyber pulls this large amount of wBTC from Uniswap. This changes the exchange rate of wETH/wBTC on Uniswap from 1wBTC = 49 wETH, which is the rate given by Compound in the hoarding stage, to 1wBTC = 109.8 wETH.

4. Trade under new rate: Now that the wETH/wBTC exchange rate on Uniswap has been pumped, the attacking flash loan contract dumps its 112 wBTC onto the Uniswap market, receiving 6,871 ETH ($1.93M USD) in this trade. In this action, it receives an exchange rate of 1wBTC = 61.3 wETH. This is about 25% higher than the original rate it received on Compound, leading to a profit of 1,371 ETH ($385,000 USD).

5. Repay loan: After the profit has been gained, the flash loan contract repays the original 10,000 ETH loan from dYdX. This is required, or else an error will be raised and the transaction will not complete. In total, the attacker spent 0.03 ETH ($7.47 USD) to execute the transaction and gained about $385,000 USD worth of cryptocurrency. It then paid back the Compound loan.

Zero-Knowledge Proof

A zero-knowledge proof is a cryptographic method or protocol where party A (the prover) proves to party B (the verifier) that a statement is true without revealing any information other than that the statement is true.

Let’s consider another example. Say the prover wants to prove to the verifier that they know the correct password for logging in to a website. The current method many websites use is to store a hash of the user’s password in their database. When the user wants to log in, the following sequence takes place:

1. The user sends the password as plain text to the server.

2. The server encrypts the password using a standard encryption algorithm, such as MD5.

3. If the newly generated MD5 hash matches the hash stored in the database, then the password entered is valid.

Man in the middle attacks

If a hacker compromises the communication between the user and the server, it is possible to intercept the plain-text password.

Brute force and dictionary attacks

If a website’s database is breached, a hacker can potentially decrypt the user’s password through various methods, including brute force using trial and error or dictionary attacks using a list of words or phrases.

In a zero-knowledge approach, a user can prove they have a valid password without the need to reveal what it is—the server does not store any variation of the password, not even a hash. This can be done by implementing the Thinbus Secure Remote Password protocol (SRP):

1. The server stores a randomly generated salt, or random data that is used as an additional input, and a verifier that cannot be decrypted into the password.

2. When the user logs in to the website, they send a one-time value used only for that particular login. Future messages will look very different. The server receives this one-time value, and through the SRP can verify whether the message received was sent by a user with a valid password. Figure 7-17 illustrates.

Figure 7-17. Flow of actions in the registration action of the SRP

Implementation of a zero-knowledge proof significantly improves the privacy and security of many systems. However, it introduces additional costs in processing power and hard drive space. Another downside is that it requires the two parties (prover and verifier) to interact directly with each other.

These downsides would not matter in the case of a website, but implementing zero-knowledge proofs in a blockchain would have a significant impact, for a few reasons:

• Blockchain miners maintain a copy of the entire blockchain history, which gets big very fast as network usage scales. Adding more data makes this problem even worse.

• In a blockchain network, the sender of a transaction wants to prove that the transaction is valid, and the miners each verify that validity. The problem is that the sender does not communicate directly with every miner. Rather, the sender broadcasts out transaction details and miners verify the transaction—a process that does not involve direct, one-to-one interaction.

So, in order for a blockchain to adopt a zero-knowledge proof method, it must be succinct, to allow for better scalability, and noninteractive, so that nodes in the network can verify zero-knowledge statements from nodes they are not communicating with directly. With this method, the sender (prover) of the transaction can broadcast out one piece of data and the miners (verifiers) can verify the transaction’s validity without any additional interaction with the sender. The data that the transaction sender broadcasts to the network must be very small in size, because that data will be stored on the blockchain.

Zcash

Zcash is a privacy-focused blockchain that provides senders of a transaction the option to make transaction information public or private. Private Zcash transactions use zk-SNARKs. Zcash’s implementation of zk-SNARKs has provided the community with evidence of how useful this can be to public blockchains. Notably, it:

With ring signatures, anyone from a predefined group can sign transactions, increasing the difficulty of determining the identity of the actual signer. Any one of the group members could be sending the transaction, concealing the sender and increasing privacy. The larger the ring, the higher the chances of concealment. The Monero cryptocurrency currently uses this technology, in addition to using decoy outputs to hide UXTOs.