Deep dive into private state - Censorship.wtf

On privacy & censorship resistance (0:40)

Privacy is :

• A human right, and everything should be private by default.
• Preventing discrimination and censorship based on information that shouldn't be revealed.
• Revealing only the exact information needed for a particular application or transaction (like ZK Proofs)
• A prevention against third parties from censoring based on accessing information they shouldn't have.
• Preventing censorship by sequencers who can't see inside transactions (encrypted mempools)
• Already being used and discussed in the Ethereum context as a way to prevent censorship.

Implementing programmable privacy (2:50)

Aztec Network is a privacy-focused Layer 2 that works on Ethereum and is fully programmable. For Aztec, privacy means shielding user identity, function execution, and state.

Aztec's goal is for any third party observing a transaction to learn nothing - just that someone did something on some state/function/contract. They want to ensure zero information is leaked in transactions, while retaining full programmability.

Private execution (3:45)

Aztec moves execution from sequencers/nodes to client-side to ensure privacy :

1. When a user sends a transaction, it is executed locally and a zero-knowledge proof of validity is generated.
2. Transactions in the mempool are zero-knowledge proofs (zk-SNARKS precisely) that prove execution validity with opaque state changes.
3. For each contract function, a unique circuit is generated to compile it for client-side proof generation.

Circuits are used instead of a Virtual Machine to enable efficient proof generation on consumer devices.

Each function call generates a ZK proof that is aggregated recursively into a kernel circuit.

The kernel circuit aggregates the call stack and hides information about the specific functions/contracts executed.

This produces a single succinct proof for the full transaction that can be generated on a mobile device.

To enable private client-side execution, the state needs to be represented in a way amenable to this.

Private state (5:50)

Aztec cannot use account-based storage like in a Virtual Machine, as it would leak info with multiple users and state updates.

For private execution, Aztec uses a UTXO-like model to represent state instead.

Like Zcash and Bitcoin, custom state nodes represent state, defined per smart contract.

Nodes are fully customizable to represent any application state, not just payments. Example : a card game could have nodes representing each card's attributes.

This UTXO-like representation of custom state nodes enables private execution without leaks.

Notes & Global state trees (7:25)

Users store state nodes locally in their wallet, representing their own private state.

To send info to others, users create encrypted nodes broadcast on-chain, provably sending to recipients.

When using a node in a proof, membership in the tree must be proven. Nodes also commit to a global data commitment tree to prove they aren't created from thin air.

Consuming/deleting a node is done by emitting a nullifier (a hash of the node mixed with a secret)

The nullifier has no link to the node commitment, allowing state updates without linked transactions.

Aztec uses a Rust-like domain-specific language "Noir" to write circuits and contracts interacting with private state.

Updating & reading data (09:30)

Updating state consumes the old node (emits nullifier) and creates a new one. There is no link between the two. Reading a node's value requires destroying and recreating it with same value.

This ensures users have a fresh version of state since they don't know which block their transaction lands in :

• If they read an old state, the nullifier will already be in the tree, causing a double spend.
• Valid transactions require a valid proof and no duplicate nullifiers.

This allows private execution and state changes per user. However, reading state implicitly invalidates other transactions referring to that state.

This is good for private order books, but not shared state like AMM's liquidity pools.

So Aztec uses a hybrid model where transactions have opaque state changes and public execution requests.

Public execution (12:15)

Transactions can emit public execution requests to the sequencer along with opaque state changes.

Public functions use account-based storage like Ethereum Virtual Machine, allowing concurrent updates.

Having both private and public state enables operations like:

• Gather/unlock funds privately, swap publicly, re-shield privately.
• Each private transaction can enqueue public requests.

The developer manages what needs to be private vs public. However, this introduces a censorship vector by revealing some transaction actions.

Decentralizing decentralization (13:30)

Aztec is building a private-first network where censorship resistance is critical.

Aztec's promise is to have fully decentralized sequencers and provers from Day 1, and no progressive decentralization.

They are developing governance mechanisms compatible with decentralization to provide security and upgrades while guaranteeing censorship resistance.

Sequencing (14:40)

Aztec is converging on an algorithm called "Fernet" for random election of staked sequencers based on a VRF to promote decentralization.

For provers, they are evaluating cooperative and competitive networks. Competitive promotes innovation, cooperative promotes diversity and lower censorship risk.

Aztec's rollup design allows parallelizing proving across many small nodes that can run on consumer hardware for full decentralization.

In summary, Aztec aims to build robust, private, censorship-resistant protocols through community participation, and generate open source knowledge to help other Ethereum networks.