# Glossary Key terms and concepts in Armchain documentation. *** ### aBFT (Asynchronous Byzantine Fault Tolerance) A consensus property where the network reaches agreement even if up to one-third of validators are faulty or malicious, without any timing assumptions. Armchain's Lachesis consensus is aBFT. ### Access List A list of addresses and storage slots that a transaction will access (EIP-2930). Included in Type 3 transactions to optimize gas usage. ### Archive Mode The default garbage collection mode (`--gcmode archive`) in Armchain. Preserves all historical EVM state, meaning no trie data is ever pruned. Required for `eth_call` at arbitrary block numbers and historical tracing. See [Node Types](/node-operators/node-types.md). ### ARM The native token of the Armchain network. Used to pay gas fees, stake as a validator, and participate in governance. ### Atropos The single finalized event elected per frame in the Lachesis consensus. There is a 1:1 mapping between Atropos events and blocks. Atropos is selected through weighted voting by root events across frames. See [Consensus](/architecture/consensus.md). ### Block A batch of transactions ordered and finalized by the consensus layer. Blocks are created by processing events from the DAG. ### BIP-39 A standard for generating a mnemonic phrase (12 or 24 words) that encodes a cryptographic seed for HD wallet generation. ### BIP-44 A standard for HD wallet derivation paths: `m / purpose' / coin_type' / account' / change / address_index`. Armchain uses coin type `65536`. ### Chain ID A unique identifier for a blockchain network. Armchain devnet is `55`. ### Coin Type The BIP-44 coin type for Armchain: **65536**. Used in derivation paths to distinguish Armchain keys from keys on other networks. ### DAG (Directed Acyclic Graph) A data structure where events (containing transactions) reference parent events, forming a graph without cycles. Armchain uses a DAG instead of a linear chain for event ordering. ### Database Preset The `--db.preset` flag selects the database engine and storage layout. Options: `ldb-1` (LevelDB, default), `pbl-1` (Pebble), `legacy-ldb`, `legacy-pbl`. See [Node Types - Database Configuration](/node-operators/node-types.md#database-configuration). ### Emitter The component in the Armchain node that creates DAG events at regular intervals (\~110ms minimum), packaging transactions from the mempool and submitting them to the Lachesis consensus engine. ### Epoch A time period in the Lachesis consensus during which a set of validators participates. Epochs end when enough blocks are sealed. Validator sets can change between epochs. ### EIP-1559 An Ethereum improvement proposal that introduces a base fee (burned) and a priority fee (tip to validators). Armchain uses the EIP-1559 fee model. ### EIP-2718 A standard for typed transaction envelopes. Type 3 transactions use this format with `0x03` as the type prefix. ### Event A unit of data in the Lachesis DAG. Each event contains transactions, references to parent events, a Lamport timestamp, and a validator signature (ML-DSA44). Events are the fundamental units processed by the Lachesis consensus engine. ### EVM (Ethereum Virtual Machine) The runtime environment for executing smart contracts. Armchain runs a London fork of the EVM, fully compatible with Solidity and Vyper contracts. ### Fakenet A local development network for testing. Runs one or more validators with pre-funded accounts and instant finality. See [Fakenet Guide](/node-operators/fakenet.md). ### Full Mode A garbage collection mode (`--gcmode full`) that keeps only the 16 most recent state tries (`TriesInMemory = 16`) and prunes older state via greedy GC. Reduces storage compared to archive mode at the cost of limited historical state access. See [Node Types](/node-operators/node-types.md). ### Finality The guarantee that a confirmed transaction cannot be reversed. Armchain achieves **instant finality**, meaning once a transaction is included in a block, it is final. ### Frame A consensus round in the Lachesis protocol that groups events for processing. Frames are the granularity at which Atropos events are elected. Each frame may produce one block (via its Atropos) or be skipped if no Atropos can be elected. ### Gas A unit of computational work on the EVM. Every operation has a gas cost. Users pay gas fees in ARM. ### Hardened Derivation A type of HD key derivation (indicated by `'` or `h` suffix) where child keys cannot be derived from the parent public key. Armchain uses hardened derivation for all path components. ### HD Wallet (Hierarchical Deterministic Wallet) A wallet that derives multiple key pairs from a single master seed, enabling backup of all accounts with one recovery phrase. ### Intrinsic Gas The minimum gas required for a transaction before any EVM execution. Includes base cost (21,000) plus data cost. Type 3 transactions have higher intrinsic gas due to larger signature data. ### Light Mode A garbage collection mode (`--gcmode light`) with the most aggressive state pruning. **Not** a light client protocol: the node still downloads and validates all data. Only the on-disk state retention is minimized. See [Node Types](/node-operators/node-types.md). ### JSON-RPC The API protocol for interacting with Armchain nodes. Compatible with Ethereum's JSON-RPC specification (`eth_*`, `net_*`, `web3_*` namespaces). ### Keccak-256 The hash function used for address derivation, transaction hashing, and various EVM operations. Also called SHA-3 in Ethereum contexts (though technically distinct from NIST SHA-3). ### Lachesis Armchain's aBFT consensus protocol. Based on a DAG of events, it provides instant finality without relying on a single leader or synchronous communication. Key concepts include events, roots, frames, and Atropos elections. ### ML-DSA44 (Module-Lattice Digital Signature Algorithm) The post-quantum signature algorithm used by Armchain. Standardized in FIPS 204 (NIST). Security level 2 (\~128-bit). Replaces ECDSA/secp256k1 throughout the stack. ### MLWE (Module Learning With Errors) The mathematical problem underlying ML-DSA44's security. Believed to be hard for both classical and quantum computers. ### NodeDriver An intermediary on-chain contract through which the Armchain node pushes system-level transactions (epoch sealing, validator deactivation) to the SFC contract. Deployed at genesis. ### Nonce A sequential counter for each account that prevents transaction replay. Each transaction must use the next expected nonce. ### Opera The name of the Armchain node binary, built from the `armchain-client` repository. ### pqcRecover An EVM precompile at address `0x13` that recovers a signer's Ethereum address from an ML-DSA44 signature blob. The post-quantum equivalent of `ecRecover` (`0x01`). See [EVM Integration](/architecture/evm.md). ### Post-Quantum Cryptography (PQC) Cryptographic algorithms designed to be secure against attacks by quantum computers. Armchain uses ML-DSA44, a lattice-based post-quantum signature scheme. ### RLP (Recursive Length Prefix) The encoding format used for serializing transactions and other data structures in EVM-compatible blockchains. ### Root A special event in the Lachesis DAG that qualifies to participate in the Atropos election. A root must be forkless-caused by ≥ 2/3 of validator weight from the previous frame. Each validator can have at most one root per frame. ### Seed A 32-byte random value used to deterministically generate an ML-DSA44 key pair. In HD wallets, seeds are derived from the master seed via HMAC-SHA512 chains. ### SFC (Special Fee Contract) The core on-chain governance contract deployed at genesis. Manages validator registration, stake delegation, reward distribution, epoch sealing, slashing, and network parameters. Owned by a single address set at genesis (root of trust). See [Consensus](/architecture/consensus.md). ### Shor's Algorithm A quantum algorithm that can efficiently solve the discrete logarithm and integer factorization problems, breaking ECDSA and RSA. This is the primary quantum threat that ML-DSA44 mitigates. ### Signature Blob The concatenation of a raw ML-DSA44 signature (2,420 bytes) and the signer's public key (1,312 bytes), totaling 3,732 bytes. Included in Type 3 transactions because ML-DSA44 does not support public key recovery. ### Snap Sync A synchronization mode (`--syncmode snap`) that downloads a recent state snapshot and only replays recent history, instead of replaying all transactions from genesis. Faster initial sync but cannot query state before the snapshot point. See [Node Types](/node-operators/node-types.md). ### Type 3 Transaction Armchain's post-quantum transaction type. Uses ML-DSA44 for signing, EIP-1559 for fee market, and includes a `signatureBlob` instead of ECDSA's `v`, `r`, `s` fields. ### TriesInMemory The number of recent state tries kept in memory/disk by a `full` mode node (default: 16). State tries older than this threshold are garbage-collected. ### Validator A node that participates in the Lachesis consensus by creating events, voting on transaction ordering, and signing blocks with ML-DSA44 keys. ### VecMT (Vector Merkle Tree) The data structure used to verify event membership in the DAG, enabling light client proofs and efficient consensus verification. ### Wei The smallest denomination of ARM. 1 ARM = 10¹⁸ wei. Gas prices are typically expressed in Gwei (10⁹ wei). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.armchain.org/resources/glossary.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.