Skip to main content

Concepts Overview

This page outlines Aztec's fundamental technical concepts. It is recommended to read this before diving into building on Aztec.

High level view of Aztec

  1. A user interacts with Aztec through Aztec.js (like web3js or ethersjs)
  2. Private functions are executed in the PXE, which is client-side
  3. They are rolled up and sent to the Public VM (running on an Aztec node)
  4. Public functions are executed in the Public VM
  5. The Public VM rolls up the private & public transaction rollups
  6. These rollups are submitted to Ethereum

Private and public execution

Private functions and public functions are executed in different environments.

Private Execution Environment (PXE)

Private functions are executed first on the user's device in the Private Execution Environment (PXE, pronounced 'pixie'). It is a client-side library for the execution of private operations. It holds keys, notes, and generates proofs. It is a TypeScript library and can be run within Node, such as when you run the sandbox.

Aztec VM

Public functions are executed by the Aztec Virtual Machine (AVM), which is very similar to the Ethereum Virtual Machine (EVM). To learn more about how it works and its instruction set, go to the protocol specs.

The PXE is unaware of the Public VM. And the Public VM is unaware of the PXE. They are completely separate execution environments. This means:

  • The PXE and the Public VM cannot directly communicate with each other
  • Private transactions in the PXE are executed first, followed by public transactions

Private and public state

Private state works with UTXOs, or what we call notes. To keep things private, everything is stored in an append-only UTXO tree, and a nullifier is created when notes are invalidated. Nullifiers are then stored in their own nullifier tree.

Public state works similarly to other chains like Ethereum, behaving like a public ledger. Public data is stored in a public data tree.

Public vs private state

Aztec smart contract developers should keep in mind that different types are used when manipulating private or public state. Working with private state is creating commitments and nullifiers to state, whereas working with public state is directly updating state.

Accounts and keys

Account abstraction

Every account in Aztec is a smart contract (account abstraction). This allows implementing different schemes for transaction signing, nonce management, and fee payments.

Developers can write their own account contract to define the rules by which user transactions are authorized and paid for, as well as how user keys are managed.

Learn more about account contracts here.

Key pairs

Each account in Aztec is backed by 3 key pairs:

  • A nullifier key pair used for note nullifier computation
  • A incoming viewing key pair used to encrypt a note for the recipientt
  • A outgoing viewing key pair used to encrypt a note for the sender

As Aztec has native account abstraction, accounts do not automatically have a signing key pair to authenticate transactions. This is up to the account contract developer to implement.

Noir

Noir is a zero-knowledge domain specific language used for writing smart contracts for the Aztec network. It is also possible to write circuits with Noir that can be verified on or offchain. For more in-depth docs into the features of Noir, go to the Noir documentation.

What's next?

Start coding

Dive deeper into how Aztec works

Explore the Concepts for a deeper understanding into the components that make up Aztec: