DOCSEARCHbyAlgolia
Submit Docs

Aztec Protocol Monorepo

repository·next·Indexed 19 days ago

https://github.com/aztecprotocol/aztec-packages

The central repository for the Aztec protocol, featuring the Barretenberg ZK prover, Noir smart contract frameworks, Aztec.js client libraries, and the core execution environment. It includes the AVM (Aztec Virtual Machine) Transpiler for converting Noir Brillig bytecode to AVM bytecode, the Aztec toolchain (aztec, aztec-up, aztec-wallet), and the BBup installer for the Barretenberg proving backend.

Tokens
1M
Snippets
2.7K
Records
4.6K
Agent score
62%

What's inside aztec-packages

  1. Overview of Aztec Node

    next

    The Aztec Node implements a sequencer node within the network. It is currently designed for local development and testing. The Node serves as the entrypoint for creating and starting a new Sequencer client, providing default components such as a local P2P client and an in-memory merkle tree database.

    It exposes methods used by clients (such as the Private eXecution Environment, or pxe) for tasks like querying network information or submitting transactions. While currently used via direct client integration, these methods are expected to be exposed via a JSON-RPC API in future iterations.

  3. Overview of Aztec Playground

    next

    Aztec Playground is an 'everything app' designed for testing and benchmarking the Aztec protocol. It provides a browser-based environment with the following capabilities:

    • Embedded Wallet: Includes a PXE (Private eXecution Environment) in the browser and supports client proofs.
    • Network Connectivity: Connect to a local network or any network supporting scoped data.
    • Contract Interaction: Supports dropping in contract artifacts, interpreting their ABI, and performing simulations or sending transactions. You can also load an existing artifact by providing its address instead of redeploying.
    • Persistence: Uses indexeddb to store artifacts, accounts, and state, allowing you to resume work without redeploying.
    • Management Tools: Supports aliasing for addresses, senders, and contracts; sender/contact management; and Authwits.
    • Benchmarking: Includes a dedicated window to display simulation and proving statistics.
    • Performance: Optimized with lazy loading for assets (like contract artifacts) and WASM, bundled via Vite (approx. 1.6MB compressed).

  4. Overview of the Pod Racing Tutorial

    next

    This tutorial guides you through building a competitive game where players' strategies are kept private using Aztec's features. You will learn how to:

    • Write and compile Noir smart contracts with private state.
    • Deploy and interact with contracts using TypeScript.
    • Configure a Vite + React project to run Aztec's WASM modules in-browser.
    • Connect to Aztec using an embedded wallet or the wallet SDK.
    • Manage private transactions, read private state, and handle transaction fees using the SponsoredFPC contract.

  5. Overview of Nightly Network Benchmarks

    next

    Aztec runs three types of benchmarks against ephemeral networks on the aztec-gke-private GKE cluster to measure network performance. Results are published to a network dashboard.

    Benchmark Types

    BenchmarkbenchmarkTypeDescription
    Inclusion sweepingress-inclusionMeasures transaction inclusion latency at 1, 5, and 10 TPS.
    Proving (simulated)simulated-provingMeasures end-to-end proving throughput using simulated delays.
    Proving (real)real-provingMeasures end-to-end proving throughput using genuine proofs (runs weekly).
    Block capacityblock-capacityMeasures how many transactions of specific shapes fit in a single block.

  6. Overview of Aztec TypeScript Client SDKs

    next

    Aztec provides several Client SDK packages for building applications, ranging from high-level application development to low-level private execution orchestration:

    • @aztec/aztec.js: The primary SDK for building applications. Use this for contract deployment, transaction creation, and account management.
    • @aztec/accounts: Contains sample account contract implementations, such as ECDSA and Schnorr accounts.
    • @aztec/pxe: A client library for the Private eXecution Environment (PXE), used to orchestrate private transaction execution and proving.
    • @aztec/wallet-sdk: Designed for integrating wallets into browsers and extensions.
    • @aztec/wallets: Provides embedded wallet capabilities for both browser and Node.js environments.
    • @aztec/entrypoints: Implements transaction entrypoints to support account abstraction.

  8. What is the Epoch Cache and how is it used?

    next

    The Epoch Cache is a component designed to reduce L1 RPC traffic by caching validator committee information per epoch. It provides essential consensus data for any given slot or epoch, including:

    • The current committee members.
    • Proposer selection (who is responsible for assembling blocks).
    • Escape hatch status (whether the censorship-resistance mechanism is active).

    It is primarily used by the sequencer, validator client, and other node components that need to determine who is authorized to propose or attest in a specific slot.

  10. Overview of the Slasher module

    next

    The Slasher module implements validator slashing for the Aztec network. It is designed to punish misbehaving or inactive validators by reducing their stake, which ensures network security and liveness.

    For standard operation, the slasher is integrated into the Aztec node and requires:

    1. The node to be configured as a validator.
    2. The validator to be selected as a proposer for a slot.
    3. The detection of slashable offenses.

    No manual intervention is required for normal operation; the slasher client automatically monitors for offenses, generates slash actions, and coordinates with the SequencerPublisher for L1 execution.

  11. Overview of ipc-codegen

    next

    ipc-codegen

    ipc-codegen is a schema-driven IPC (Inter-Process Communication) code generator that supports C++, TypeScript, Rust, and Zig.

    It takes a hand-authored JSONC schema describing a service's commands and responses and emits:

    1. Wire-type definitions: Data structures used for serialization.
    2. Typed Clients: Interfaces for calling service commands.
    3. Server-side Dispatchers: Logic to route incoming requests to handlers.

    Key Concepts:

    • Source of Truth: The JSONC schema is the single source of truth.
    • Wire Format: Uses msgpack for serialization.
    • Transport Agnostic: ipc-codegen only handles serialization. It does not manage sockets or shared memory. You must pair the generated code with ipc-runtime (which provides Unix-domain socket or MPSC shared memory transport) to move the bytes.
    • Cross-Language Compatibility: Because all languages use the same wire types and msgpack, a TypeScript client can communicate with a C++ server seamlessly.

  12. Overview of the Sentinel component

    next

    The Sentinel is a watcher component within the Aztec Node that monitors the behavior of committee members during every L2 slot. It aggregates per-slot observations into per-epoch performance metrics and is responsible for identifying validators that meet the criteria for inactivity slashing.

    Key responsibilities include:

    • Classifying proposer and attestor behavior (e.g., whether a checkpoint was mined, valid, or missed).
    • Persisting a sliding window of per-slot history and per-epoch performance.
    • Emitting WANT_TO_SLASH_EVENT with OffenseType.INACTIVITY when a validator has been inactive for slashInactivityConsecutiveEpochThreshold consecutive epochs.
    • Exposing validator statistics via RPC methods: getValidatorStats and computeStats.

    Note: The Sentinel is a watcher registered with the slasher; it does not vote or publish to L1 directly.