Libra Architecture

File Structure

• admission_control

  • Libra’s public API interface, used to receive public gRPC requests from clients
  • Admission Control (AC) handles two types of requests from clients
    • 1. Submit transactions: submit a transaction to the associated validator
      • Validation process
        • First, the transaction signature is checked
        • Then the transaction is validated by the vm_validator
        • ✅ Passes all validations
          • Sent to the mempool
            • Submission succeeds
            • Submission fails
    • 2. Update the latest distributed ledger - query storage for things like account states, transaction logs, verification, etc.
      • The request is passed directly to storage for querying

• benchmark

  • Libra’s public API interface, used to receive public gRPC requests from clients

• client

  • A Rust wrapper over the RPC client

• common

• config

• consensus

  • The consensus protocol component performs state machine replication using the LibraBFT consensus protocol.
  • The consensus component is mainly implemented as Actor modules
    • Sub-components communicate with each other via message passing
    • The tokio framework is used as the task runtime
    • Consensus data structures: BlockStore
      • TxnManager is the interface to the mempool component, supporting pulling transactions and removing committed ones.
      • StateComputer is the interface to the executor component.
      • BlockStore maintains the tree of proposed blocks, block execution, voting, quorum certificates, and persistent storage.
      • EventProcessor is responsible for handling individual events.
      • Pacemaker is responsible for the liveness of the consensus protocol.
      • SafetyRules is responsible for the safety of the consensus protocol.
    • All consensus messages are signed by their creators and verified by their receivers.

• contributing

• crypto

  • The crypto component hosts all the cryptography implementations used in Libra: hashing, signatures, and key derivation/generation.
  • Libra uses several cryptographic algorithms:
    • SHA-3 as the main hash function.
    • X25519 for key exchange.
    • Ed25519 for signatures.
    • HKDF: an HMAC-based Extract-and-Expand key derivation function (HKDF), based on RFC 5869.

• docker

• documentation

• executor

  • The main implementation of the executor component

• language

  • vm
    • The virtual machine (VM), which contains the bytecode format, the bytecode interpreter, and the infrastructure for executing blocks of transactions.
  • bytecode_verifier
    • The bytecode verifier, which contains a static analysis tool that rejects invalid Move bytecode.
  • IR: intermediate representation
    • The Move IR compiler, which compiles human-readable program text into Move bytecode.
  • stdlib
    • The standard library, which contains the Move IR code for core system modules such as LibraAccount and LibraCoin.
  • functional_tests
    • Tests for the virtual machine, the bytecode verifier, and the compiler.
  • compiler
    • The Move IR compiler compiles Move IR into its bytecode representation.
    • bytecode verifier: verifies the semantics of the compiled bytecode.

• libra-node

• libra-swarm

• mempool

  • The Admission Control (AC) module sends transactions to the mempool
  • Before the consensus module commits them, the mempool holds transactions for a period of time
  • The consensus module pulls transactions from the mempool; the mempool does not push transactions to consensus

• network

  • The network component provides peer-to-peer network services to the other validator components.
    • RPC, for remote procedure calls
    • DirectSend, for sending “fire-and-forget” style messages to a single recipient
  • The network component uses
    • Multiaddr: a scheme for peer addressing.
    • TCP: for reliable transport.
    • Noise: for authentication and peer-to-peer encryption.
    • Yamux: multiplexing substreams over a single connection.
    • Push-based gossip: for node discovery.
  • Different sub-components within the network component:
    • NetworkProvider
      • Exposes the network API to clients.
    • Peer Manager — listens for inbound connections and actively connects to other peers on the network.
    • Connectivity Manager
      • Ensures we stay connected to a node if and only if it is a qualified network member.
    • Discovery — uses a push-based approach to discover new nodes and update the addresses of existing ones.
    • Health Checker — performs periodic liveness probes to ensure peer/connection health.
    • Direct Send — allows sending/receiving messages to/from remote peers.
    • RPC — allows sending/receiving RPCs to/from other peers.

• rust-toolchain

• scripts

• state-synchronizer

• storage

  • The storage module provides reliable and efficient persistent storage for all data on the Libra blockchain as well as the necessary data used internally by Libra Core.
  • The storage module aims to:
    • 1. Retain blockchain data, especially the transactions and their outputs agreed upon by validators through the consensus protocol.
    • 2. Provide a response with Merkle proofs for any query that requests part of the blockchain data.

• target

• terraform

• testsuite

• types

• vm-validator