Why Private Accounts?

A common question we hear about Nocturne is why the protocol was designed as a “private account.” Why not another design? In this post, we distill past approaches to onchain privacy and the motivation behind the Nocturne design philosophy.

Setting the Stage

To understand the motivation behind private accounts, we need to look to the past. There have been 2 major types of onchain privacy products we’ve seen so far—alternative L1/L2s and mixers. Both categories garnered significant interest but have fallen short of reaching broader adoption due to several key UX issues.

Alternative L1/L2s

The first onchain privacy projects were standalone chains whose sole purpose was to provide a currency with privacy-preserving transfers. Monero and Dash were some of the earliest with ZCash later introducing the concept of a shielded pool via zk-SNARKs.

The core challenge alt chains face is that bootstrapping a new developer and user ecosystem is hard. Some of the only teams that succeeded in doing so last cycle were Solana, Polygon, and maybe a couple of others. If creating a new ecosystem was already hard enough, doing it with privacy as the main differentiator rather than speed, dev experience, or community is even tougher.

Mixers

Mixers such as Tornado Cash took a step in another direction. Tornado Cash was built as a set of Ethereum smart contracts that allowed users to deposit fixed denominations of funds (e.g. 0.1 ETH, 1 ETH, 10 ETH), prove ownership to those funds in zero knowledge, then withdraw exactly that amount of funds to a fresh address.

While Tornado provided a basic level of privacy on Ethereum, the UX remained clunky. You put in exactly the fixed amount of tokens and took out exactly that much. The gas cost was absorbently high (nearly 1M gas for a single deposit). Additionally, users had to manually store a set of “nullifiers” offchain (think of them as secrets that are needed to claim the deposited funds).

Hybrid

There was one additional type of product worth mentioning which was Aztec Connect—a rollup that allowed for anonymous interactions with DeFi. Though Aztec Connect was much more usable than its predecessors, the indirection of building user accounts on a rollup had compatibility issues. Custom bridge contracts were needed to interact with each DeFi protocol. Additionally, interactions from mainnet to Aztec were limited (e.g. you could not privately pay a recipient within Aztec unless you first bridged funds and then made the payment on Aztec).

Design Philosophy: Private User-Level Accounts

With past approaches in mind, our goal became relatively straightforward—build user accounts directly on L1/L2 that have close to full compatibility with existing Ethereum accounts.

Our design philosophy emphasizes two key points:

1. Compatibility is important, we should aim for near-identical experiences/capabilities when compared to public wallets

2. Scaling and privacy should be solved separately from each other

Compatibility Matters

The only way privacy on public blockchains can reach broader adoption is to meet users where they already are. If you can make/receive payments and interact with new protocols from your externally-owned account or smart contract account, you should be able to do the same from your private account. In essence, our north star became “your Ethereum account but private.”

Interacting with Nocturne v1 both internally and externally should resemble interacting with a smart contract wallet. Nocturne v1 allows users to make/receive payments privately to/from public or private accounts as well as interact with DeFi protocols. In theory, Nocturne v1 is out-of-the-box compatible with any DeFi protocol that represents state via output tokens (e.g. Uniswap swap tokens, Aave aTokens, Compound cTokens, etc). In a future version, however, we are looking to fully extend compatibility to arbitrary protocols.

Scaling and Privacy Are Separate

Many privacy projects, namely the more recent anonymity-focused L1/L2s, built solutions that partially resembled scaling solutions and partially resembled privacy solutions. Historically, the gas overhead of verifying proofs and updating an onchain shielded pool has been expensive, thus scaling measures were necessary. The problem is that the more scaling measures you take (e.g. an alt L1), the less compatibility you have with existing ecosystems.

For our v1, we struck a balance between compatibility and scaling. The cost of naively updating an arbitrary shielded pool onchain was unusable (over 1M gas per deposit and per spend). We employed several gas optimization techniques including batch verification of spend proofs and zk commitment tree updates. This lowered gas costs to roughly 100k gas per deposit and 350-400k per spend while maintaining compatibility with existing use cases. Seamless interactions with external protocols and payments between public and private accounts remain intact. If you want to use Nocturne on mainnet, it will have a reasonable gas overhead. If you don’t want to pay the mainnet cost, you can still use it on an L2 if that is your preferred ecosystem. Meet users where they are.

Long Term

Onchain privacy has had several attempts over the past few years. The Nocturne design philosophy draws on learnings from these attempts and emphasizes simplicity and familiarity for end-users above all else. Our v1 will be a first step towards more compatible onchain privacy that should not resemble a privacy “tool” or new “ecosystem” but rather just an “account.” Our long-term vision as we continue building new versions is to make the experience so seamless that by default, every Ethereum address automatically has a private account. In short, a parallel account layer for privacy.