DOCSEARCHbyAlgolia
Submit Docs

Aztec.js

website·Indexed 30 days ago

https://aztec-docs-dev.netlify.app/

Documentation for Aztec.js, including the TypeScript API reference, connecting to local networks, and deploying smart contracts. It covers contract interactions, transaction fee management via Mana and Fee Juice, and integration with the Aztec.nr Noir framework for developing and testing private smart contracts.

Tokens
689.9K
Snippets
4.2K
Records
5.6K
Agent score
74%

What's inside Aztec.js

  1. Overview of Aztec node interactions with Ethereum L1

    Aztec nodes use the viem library to interact with the Ethereum L1 blockchain via type-safe JSON-RPC methods. Different node components perform specific RPC tasks:

    • Archiver: Monitors L1 for new blocks and events.
    • Sequencer: Proposes blocks and submits them to L1.
    • Prover: Submits proofs to L1.
    • Validator: Reads L1 state for validation.
    • Slasher: Monitors for misbehavior and submits slashing payloads.

  3. Overview of @aztec/stdlib and its type dependencies

    The @aztec/stdlib package (version 5.2.0) provides core types and utilities for interacting with the Aztec network. It relies on several other Aztec packages for specific type definitions, including @aztec/aztec.js for event filtering, @aztec/ethereum for L1 addresses, @aztec/foundation for cryptographic and basic types (like Fr, EthAddress, and Point), @aztec/key-store for privacy keys, and @aztec/kv-store for storage implementations.

  5. Overview of L2 to L1 message passing via Outbox

    The Outbox is an L1 contract that handles messages sent from L2 to L1. The Rollup contract inserts message roots via insert() as proofs land. Portal contracts then call consume() to receive and process these messages. Because a single proof may cover only a prefix of an epoch's checkpoints (partial proof), an epoch may have multiple roots corresponding to the number of checkpoints covered.

  6. Overview of the Authentication Witness (AuthWit) scheme

    The Authentication Witness (AuthWit) is a mechanism for authenticating actions on Aztec, enabling users to allow third parties (such as protocols or other users) to execute actions on their behalf. An AuthWit is data (e.g., a signature, a secret, or a token) that proves a specific message_hash is authorized.

    The message_hash is structured as: hash(consumer, chain_id, version, inner_hash)

    • consumer: The address of the contract consuming the message.
    • chain_id: The ID of the chain where the message is consumed (prevents cross-chain replay attacks).
    • version: The version of the chain.
    • inner_hash: The hash of the actual action being approved (e.g., a hash of the caller, the action name, and the arguments).

    Authentication Flows:

    • Private Context: Executed on the user's device. Contracts use oracles to ask the user for a signature/proof. A nullifier is emitted by the consumer contract to prevent replay attacks.
    • Public Context: Executed by the sequencer. Uses an authentication registry to store authorized message_hash mappings. The account contract calls set_authorized to grant permission, and the consumer contract calls consume to verify and revoke the permission.

  8. Overview of the Aztec Wallet Protocol

    The Aztec wallet SDK implements a secure protocol for dApps to discover and communicate with wallets. The protocol consists of three distinct phases to ensure security and prevent eavesdropping:

    1. Discovery: The dApp broadcasts a request, and available wallets respond with their information.
    2. Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) is used to establish a shared secret for encrypted messaging.
    3. Secure Messaging: All subsequent communication between the dApp and the wallet is encrypted using the shared secret.

    This architecture supports multiple wallets and includes a user-verification step (emoji codes) to ensure the dApp is legitimate.

  11. Overview of the Aztec to Aave cross-chain DeFi integration

    This integration enables a full flow where users deposit tokens from Layer 2 (L2) into Aave on Layer 1 (L1), earn yield, and claim the assets back on L2. The architecture consists of three primary components:

    1. L2 Bridge (Noir): Manages the burning and minting of tokens and handles cross-chain messaging for both public and private operations.
    2. L1 Portal (Solidity): Executes the actual deposits into Aave and handles withdrawals including accumulated yield. It is responsible for consuming and creating messages.
    3. Mock Aave (Solidity): A simulation of yield generation used for local development and testing.

  12. Overview of Aztec On-chain Governance

    The Aztec network uses an on-chain governance system on Ethereum (L1) to upgrade rollup contracts and adjust network parameters. The system is designed to ensure backwards compatibility (users can always bridge assets from any previous rollup version) and that only the most recent 'canonical' rollup receives block rewards.