🧭Cryptographic Explainer

Firn's unique account-based architecture makes it unprecedentedly efficient.

This post describes Firn's cryptographic architecture, including what data, exactly, is stored on-chain, and how Firn’s browser-based client interacts with that data. For a slightly more advanced survey, please see our technical whitepaper.

Account-Based Privacy

The crucial thing to understand is that Firn is account-based; every other live-and-working cryptographic privacy protocol is UTXO-based. This distinction is analogous to that between Ethereum and Bitcoin. Indeed, you can think of Firn as something like "Ethereum, but private"; other protocols—like Zcash, Monero, and Aztec—are more like "Bitcoin, but private."

Firn’s state consists of a global table of accounts. (These are analogous to those constituting Ethereum’s global account table, but they exist within Firn’s contract.) Just as Ethereum associates, to each account, a balance—and also code, storage, etc. in the case of contracts, but let’s ignore that—Firn associates, to each account, an encrypted account balance, encrypted under its owner’s key. Each account’s balance can only be viewed by the account’s owner.

When you deposit into Firn, you credit your own balance’s account. When you withdraw, on the other hand, you debit your account. Crucially, Firn withdrawals take place in such a way that it’s not visible which account is being debited. In other words, your account will be hidden within a number of other accounts, when the withdrawal takes place; it will not be publicly discernible which among these accounts initiated the withdrawal. This is where Firn’s privacy comes from. A depiction of this process is given below.

A depiction of Firn's account-based architecture.

This diagram is simplified; in reality, Firn deposits are also private. Firn supports private transfers. These work similarly to private withdrawals, except that, in a single transaction, the sender’s and receiver’s accounts are simultaneously debited and credit, respectively.

As it turns out, Firn’s account-based architecture has immense benefits, and makes it vastly more efficient than UTXO-based privacy protocols. Let’s explore this fact. The key property is that, when your account state changes—say, when you receive a transfer—your old account is overwritten by your new account! In UTXO-based settings, when you receive a payment, of course no overwriting takes places, and your “holdings” can be, in general, spread throughout hundreds of UTXOs.

This difference—fundamental to the definition of the account-based model—has immense ramifications. In short, in Firn, retrieving your own account state is an extremely simple, instantaneous task; you must only query a table entry, and decrypt the resulting ciphertext. In UTXO-based privacy protocols, it’s far harder. It requires that you download every transaction posted to the system since you last synchronized, trial-decrypt each transaction (to learn whether it was to you or not), add the resulting holdings, and cache them. If you do this on a new device, it will require that you start from the very beginning! The data download requirements here can be in the gigabytes.

The situation here, moreover, differs crucially from that of Bitcoin, because of the privacy factor. In Bitcoin, wallets can—and do—outsource the task of state management to powerful external servers, which handle the burden of downloading, storing, and indexing the blockchain’s state. This option is not available in the private setting, since it would require outsourcing your secret information to the external server. Rather, each participant must bear this burden locally.

A similar fact holds regarding generating zero-knowledge proofs. In UTXO-based settings, to generate a proof, you must make reference to the entire privacy system’s state. In Firn, you only need to make reference to a constant amount of state, which can be queried in an instant.

Firn's Lightweight Browser Client

This is how Firn gets away with running entirely in an extremely lightweight browser client. Firn’s front-end is hosted entirely statically on IPFS. Firn has no off-chain rollup (like Aztec does), and Firn proofs can be generated by the browser entirely unassistedly. Firn’s browser client must only download a few hundred bytes (compared to megabytes in the case of Aztec); it’s completely stateless, and stores nothing locally (unlike Aztec); finally, Firn synchronizes instantly, even on fresh devices. Firn’s liveness depends only on the L1’s liveness. During synchronization and proof-generation, Firn communicates only through the selected wallet (whose RPC is controlled by the user), and does not initiate any “backdoor” connections to Firn-specific services. (When you actually dispatch a withdrawal or transfer, a one-time zero-knowledge proof gets sent to the Firn relay, which pays gas and forwards it to the blockchain. This proof reveals nothing to the relay. The relay does not collect any IP information.)