What is the promise of encrypted transactions for DEFI?

Decentralized finance projects represent an exponentially growing segment of the blockchain market, but suffers from a major drawback — lack of privacy. Unfortunately, blockchains publish all transactions, which means that accounts and balances within DeFi applications are public, opening up issues with financial privacy.

Additionally, lack of privacy in the blockchain can lead to larger issues. Most blockchain issues only present major issues when transactions and transaction data is public.

• Delay or Censorship attacks miner or gas related: Data from specific exchanges or applications can get preferential treatment, or transactions from specific users can be censored. Examples of this include Front-running of (DEX) and the current problems with MEV
• Public access/Social Engineering attacks: When data on account balances and transactions is public, it can be tracked and attacked. Tracing transactions back to individuals can result in directed attacks that involve phishing.

Putting privacy on-chain

The obvious solution to the issue of data privacy, would be to make data and transactions private. Private transactions are seen as the ultimate solution for issues of public transparency on the blockchain. The sender of the transaction should be able to have the ability to produce the transaction such that only the receiver should be able to read the data: Sender, amount, data, receiver.

On the other hand, Provers should only be able to create a witness of the transaction, such that the transaction is valid without seeing any more data than the verifiers. Further verifiers should be able to verify without knowledge of sender, receiver, etc.

Zero-knowledge and privacy

Implementations of private transactions are based on zero-knowledge proofs, which enable statements to be verified without revealing the information of the statement itself. To obfuscate data, private transactions rely on several forms of cryptography that enable the concealing the inputs and outputs of transactions, verifying ranges, ensuring membership, and provide verification of state updates.

These methods eventually culminate in zero-knowledge state transitions known as zkRollups. In the case of zero knowledge protocols like PLONK, rollups use logic circuits based on polynomial commitments to validate transactions (https://vitalik.ca/general/2019/09/22/plonk.html).

Private transactions

Private transactions can be designed for transfers, mints, and mixing transactions. Private transactions are constructed in several stages.

• Setup: The first stage is the set-up wherein a private key is generated from multi-party computation, which requires at least one honest party in order to be secure. In cases such as PLONK, the limitations of key generation can be overcome by generating the key in a dynamic manner, where new users can join the network, and update the key.
• Construction: After the public key/private key generation and setup, transactions can be constructed and signed by the sender of the message. In current frameworks like Bulletproofs and PLONK, messages are constructed and validated as an arithmetic circuit.
• Validation: Transactions are typically validated and bundled into rollups by a consensus layer that confirms validity and determines the ordering of transactions.
• Publishing: Once validated, rollups can be published by relayers on-chain to update the state of a specific smart contract. After they have been published it is still possible to invalidate these state transitions by way of fraud proofs.

Functionality

As shown stated previously, transactions can accomplish a variety of different outcomes, by translating functions into arithmetic circuits.

One such application of this technology is Cloak. https://github.com/stellar/slingshot Cloak is a protocol that is built using Bulletproofs and zkRollups to encrypt transaction amounts between different assets. At its core, Cloak is composed of several operations that can be represented as arithmetic circuits this includes: shuffle, merge, split, and range check. With these operations, the Cloak protocol is able to maintain the privacy of inputs, amounts, and outputs from its validators.

https://cathieyun.medium.com/building-on-bulletproofs-2faa58af0ba8

Using private transactions

Private transactions are primarily used to obfuscate the amounts being sent, as well as concealing orders in decentralized exchanges. One of the limitations of current privacy protocols, comes from the operations that can be used in the construction.

Layer 2 zero-knowledge protocols for private transactions rely on a storage layer that can index and authenticate the location of transactions within each rollup. In many protocols including zkSync, this storage layer is represented as an authenticated database that can publish a Merkle root for each rollup.

Transactions that are processed using zkRollups with account balances stored on a smart contract on a main chain, and are updated through relayers, and verified by using state transition proofs represented as SNARKs. This implementation guarantees that data cannot be corrupted, because disputes can be handled deterministically on-chain by creating fraud proofs with the the published SNARKs.

Publishing on-chain

1. Users sign transactions and submit them to validators.
2. Validators roll up thousands of transactions together in a single block and submit a cryptographic commitment (the root hash) of the new state to the smart contract on mainnet along with a cryptographic proof (a SNARK) that this new state is indeed the result of the application of some correct transactions to the old state.
3. Additionally to the proof, the state ∆ (a small amount of data for every transaction) is published over the mainchain network as cheap calldata. This enables anyone to reconstruct the state at any moment.
4. The proof and the state ∆ are verified by the smart contract, thus verifying both the validity of all the transactions included in the block and the block data availability.

The tradeoffs of Privacy

Privacy offers great opportunities for trustless consensus systems, but it leads to some drawbacks. Private transactions are limited in the scope of what they can do, it is difficult to create a Turing-complete private operations.

• Generation of the Proofs
• Size of proofs
• Limitations on what can be done
• Lack of transparency in transactions and blockchain data.

Storage in Layer 2 Privacy solutions

A large portion of zero-knowledge is the creation of the proofs for privacy with a storage mechanism, these transactions need to be stored, and are traditionally stored in a structure that represents a Merkle tree.

In order for this system to work, the transactions must be able to be verified in each Merkle root, and to be accessed by the users of the system. This leads to a question of where the data is being stored. Many protocols store data for the rollups on a centralized database that can be accessed through centralized Relayers which anchor this data to the chain in the form of commitments.

There are different forms of data that exist within the zero-knowledge privacy protocol. Data is used in zkRollups, as the Merkle hash that represents the bundled transactions for the state update to the smart contracts on the mainnet, and in SNARKs which can be published on-chain or in commits. With the exception of anchoring commitments on-chain, this data needs to be stored and accessed off-chain in a verifiable manner.

• Global state: this represents state that needs to be synchronized across the Layer 2 privacy protocol because it represents the UTXOs and updates that compose the rollups. This data is encrypted with respect to the senders and receivers, and is used for verification and validation of the state transitions, as well as synchronizing the local state of specific accounts. It is also possible to store SNARKs in a global state themselves, in order to push multiple SNARKs to different chains, to access the same data. Obviously, this lacks overall transparency of transactions, and the transaction data itself.
• Local/Relayer state: represents Personal data/unencrypted that is constructed from the global state using a private key. Most of the data is on the user-side because it is public data that represents the global state of the system.

The storage layer of these Layer 2 protocols needs to match a set of requirements:

• Authenticated and Verifiable
• Off-chain with connection to the Layer 2 Solutions
• Queryable for Commitments and Transactions

While consensus protocols can use traditional LevelDB systems for updates, these systems require a specialized API, as well as the need for these protocols to maintain and provide the data layer for Relayers and Validators that are syncing onto the network.

Using data in a privacy protocol

Since the global state of privacy protocols is encrypted, it is difficult to use this data in a real-world context. If two separate protocols use encrypted amounts and transactions to make order-matching engines, it is an open question as to how these order-books can be aggregated, or how the data can be used in any descriptive or analytical method.

Zero-knowledge protocols rely on multi-party setup, and UTXOs depend on acceptance or inclusion in an unspent set. In order to aggregate data, it is necessary to create larger global sets that represent the combination of multiple other transaction privacy layers.

The next step, would be to have SNARKs built-in on multiple consensus protocols, so that states could be used freely in other implementations. This presents concerns with double-spends, which implies that there needs to exist some bridge. At this point, data is encrypted, and validated based on some predicate, which means that it is difficult to use the data itself, after transactions or updates have been processed.

A Need for a Data Layer

One such project that requires a data layer for encrypted transactions, is the decentralized exchange: twilight.finance. Twilight.finance uses a similar merge, shuffle, perspective with groups in anonymity. It is built using a UTXO model with a private and trustless order-matching system. Additionally, it has the capacity to upgrade its transaction complexity by using zkVM for state machine updates.

In order for Twilight.finance to manage the order books and limit orders, its validators must be able to have access to the current unspent transaction outputs, and must synchronize global state in a consistent and verifiable manner. Its data layer must enable:

• Validation and Verification for Orderbook matching
• Synchronization and Authentication for Global State from the Layer 2 network
• Verifiability of transactions, and ability to stream Global state updates to get local unencrypted state
• Maintain uptime for the nodes and data layer, and ensure efficiency of running data nodes

Twilight.finance can build out a Merklized data layer on top of LevelDB like Ethereum, Binance Chain, or Polkadot, but it will run into the same issues with scaling the data layer that these nodes have. Proxima DB provides a database for these transactions that is blockchain and consensus agnostic.

Private transactions in the wild

There exist several private chains including zcash and Monero, but a lot of the new developments in transaction privacy is through layer 2 solutions that interact with multiple chains.

zkSync
One layer 2 solution that interacts with other blockchains is zk-sync. zk-sync is a protocol that uses zk-rollups and solution proofs to solve for blockchain transaction availability. The main principle is to lower the cost of transactions by bringing computation and storage off-chain. State transitions are validated on the main chain via SNARKs, and published. In this instance transactions must be pushed to blockchain through relayers. While it is initially transparent, in order to create private transactions the costs must be low, and they must be able to be verified and processed by the consensus in a cost effective manner. The core issue with this privacy is to manage the costs and obstacles to the proof creators.

zkVM

zkSync is designed to provide privacy of amounts and transfers, but it does not enable verification and validation of virtual machine operations and state updates. zkVM is a proposed solution to this problem, it constructs virtual machine operations, by tying them to specific opcodes. While this is a promising implementation it is not yet in production.

Struggles and bottlenecks

Zero-knowledge implementations for private transactions still suffer from some obstacles that prevent adoption.

• Prover generation and verification: One of the core issues with zero-knowledge is scaling the proof generation and verification of transactions for blockchain verification and for consensus-based generation of the proofs.
• Consensus-driven or layer 2 (need to scale through blockchain): As stated previously, when transactions are rolled-up, they must be ordered and validated by a layer 2 consensus or a layer 1 consensus.
• Limited functionality: Private transactions for the transfers are well-established, but it is work-in-progress to develop efficient constraint systems for a higher complexity of operations.

The Promise of Transaction privacy

Transaction privacy has many promises, but the biggest is the ability to open up blockchain finance to the general public. Without privacy, there is no method to have decentralized finance protocols, and having privacy solves issues that continue to plague the blockchain. If miners and relayers are unable to determine the content of messages on-chain, it becomes next to impossible to front-run transactions in any intelligent manner, and there is not enough information to censor transactions.