DOCSEARCHbyAlgolia
Submit Docs

Aptos Developer Documentation

repository·main·Indexed 22 days ago

https://github.com/aptos-labs/developer-docs

The official Aptos developer documentation site built with Nextra. This repository contains resources for setting up, developing, and testing projects on the Aptos blockchain, including a custom Code Cache system using Cloudflare Workers and D1, and a network-aware API reference for Mainnet, Testnet, and Devnet.

Tokens
141.4K
Snippets
461
Records
701
Agent score
74%

What's inside aptos-labs-developer-docs

  3. Common operations for Validator and Validator Fullnodes (VFN)

    main

    This section provides tutorials for performing common maintenance and operational tasks on Aptos validator nodes and Validator Fullnodes (VFN). Key operations include:

    • Upgrading Nodes: Procedures for performing software or configuration upgrades.
    • Shutting Down Nodes: Steps to safely stop validator or VFN processes.
    • Rotating Consensus Keys: Instructions for updating the keys used in the consensus mechanism.

  5. What is Block-STM?

    main

    Block-STM is a highly efficient, multi-threaded, in-memory parallel execution engine used by Aptos. It is a state-of-the-art dynamic parallelism engine that leverages the preset order of transactions by combining Software Transactional Memory (STM) techniques with a novel collaborative schedule.

    Key benefits include:

    • Dynamic Dependency Detection: It computes execution ordering on-the-fly, detecting dependencies and avoiding conflicts during execution without developer intervention.
    • Consistency: The execution output remains consistent with executing transactions according to a preset order.
    • High Performance: It enables high throughput and low latency, contributing to Aptos's fast block times (e.g., ~250ms as of Dec 2024).

  6. Overview of Aptos Networks

    main

    Aptos provides four distinct network environments for different stages of development:

    1. Localnet: A standalone tool for local development using a known version of the codebase with no external network connectivity.
    2. Devnet: A shared community resource. It receives weekly updates from the aptos-core main branch and undergoes data wipes during updates.
    3. Testnet: A shared community resource designed to mimic Mainnet configuration. Data is preserved across updates.
    4. Mainnet: The production network containing real assets.

  7. Optimize pairing-based cryptography with asymmetric pairings

    main
    When implementing pairing-based cryptographic protocols, use asymmetric pairings (where $\Gr_1 \ne \Gr_2$) rather than symmetric pairings. Asymmetric pairings, such as those over the BLS12-381 curve, are significantly more efficient at equivalent security levels compared to symmetric pairings, which are typically restricted to supersingular curves.

  8. Understand the relationship between Transactions, States, and Events

    main

    The Aptos blockchain manages three primary data types:

    • Transactions: Intended operations performed by an account (e.g., asset transfers).
    • States: The accumulated ledger state representing the values stored within all resources. Only transactions can change the ledger state.
    • Events: Ancillary data published during the execution of a transaction.

    When a transaction is executed, it produces a transaction output containing write sets (operations that manipulate the ledger state), emitted events, the amount of gas consumed, and the execution status.

  9. Choose between Entry Point and Script payloads

    main

    Aptos transactions typically use one of two payload types:

    • Entry point: A direct call to a specific function (e.g., coin::transfer or aptos_account::create_account). Most operations should be available via entry points.
    • Script (payload): A transaction that can call any entry point or public function defined within any module. This allows for atomic execution of multiple operations within a single transaction.

    Both types are supported by the Python and Typescript SDKs.

  10. Account Module High-Level Requirements

    main

    The 0x1::account module governs account lifecycle, security, and capabilities on Aptos. Key requirements include:

    • Initialization: The module initializes with a valid address_map table moved to the OriginatingAddress under the aptos_framework account.
    • Account Creation: Creating an account via create_account ensures the account state is initialized with default data.
    • Existence Checks: The exists_at function provides a non-aborting way to check if an account exists at a specific address.
    • Sequence Numbers: Accounts maintain bounded sequence numbers that increment up to MAX_U64.
    • Signature Schemes: Only ed25519 and multied25519 schemes are permitted for key rotation and signing capabilities.
    • Key Rotation Security:
      • Rotating an authentication key requires two valid signatures: one from the current private key and one from the new private key.
      • Only the account owner or a delegate with rotation capabilities can rotate keys.
    • Capability Management: Only the account owner can offer or revoke capabilities like offer_rotation_capability or offer_signer_capability.
    • Signer Creation: Creating an authorized signer is restricted to the account owner or an account granted signing capabilities via create_authorized_signer.

  11. Understand what data Aptos node telemetry collects

    main

    Aptos nodes (validators, VFNs, PFNs) collect several categories of non-personal information to monitor network health and performance:

    • Core metrics: Emitted by core components like state sync, consensus, mempool, and storage.
    • Build information: Rust build details (Rust/cargo versions, target architecture, build tag).
    • System information: Hardware and OS details (CPU, RAM, disk, network, and operating system).
    • Network metrics: Peer connectivity, inbound/outbound message counts, and message sizes.
    • Prometheus metrics: Runtime metrics for all aptos-node components.
    • Node logs: Logs of warn level and higher.

  12. Identify roles in the Delegated Staking model

    main

    The delegated staking model consists of five distinct entity types, each with specific capabilities:

    Owner

    Responsible for the pool's lifecycle and configuration. Capabilities:

    • Creates the delegation pool.
    • Assigns the Operator.
    • Sets the Operator commission percentage.
    • Assigns the Voter.

    Operator

    The node operator assigned by the owner to run the validator node. Capabilities:

    • Joins or leaves the validator set (once the pool reaches 1M APT).
    • Performs validating functions.
    • Rotates the consensus key and network addresses.
    • Receives commissions distributed automatically at the end of each epoch.

    Voter

    An entity designated by the owner to participate in governance. The voter uses a specific voter key to sign governance transactions.

    Delegator

    Any user who holds stake in the delegation pool. They earn rewards (minus operator commissions). Capabilities:

    • add stake
    • unlock stake
    • reactivate stake
    • withdraw stake

    Beneficiary

    An address designated by the operator to receive commission rewards.

    • An operator can set only one beneficiary address across all their delegation pools.
    • The beneficiary can perform unlock and withdraw operations for earned commissions.
    • Use the set_beneficiary_for_operator function to change the beneficiary.
    • Unpaid rewards transfer to the new beneficiary upon change.