rippled Documentation

The Antithesis C++ SDK allows C++ programs to interface with the Antithesis platform to enhance testing capabilities. The SDK provides three primary functional areas:

1. Assertion macros: Used to define specific test properties regarding your software or workload.
2. Randomness functions: Used to request both structured and unstructured randomness directly from the Antithesis platform.
3. Lifecycle functions: Used to signal to the Antithesis environment when specific test phases or milestones have been reached.

For detailed implementation details and full usage guidance, refer to the Antithesis C++ SDK Documentation.

The Overlay manager is responsible for establishing, receiving, and maintaining connections to peers.

Key technical details:

• Peer Object: Each individual connection is represented by a Peer object.
• Serialization: Protocol messages exchanged between peers are serialized using Google Protocol Buffers.
• Connection Types: Currently, the system only supports a single connection type: Peer.

The xrpld gRPC API uses protocol buffer definitions to provide a high-performance interface that mimics the existing JSON/Websocket API.

As of April 2020, the gRPC API supports a subset of the full xrpld API, specifically the following methods:

• tx
• account_tx
• account_info
• fee
• submit

The xrpld server software powers the XRP Ledger and is written primarily in C++. It is available under the ISC open-source license and can run in several different modes depending on its configuration.

Note: If your goal is to run an API Server or a Full History Server, you should use Clio instead, as xrpld Reporting Mode has been replaced by Clio.

The rippled source code is organized into modules that follow a specific architectural style. When navigating or extending the codebase, expect the following patterns:

• Modular Structure: Each folder contains a single, focused module designed to solve one specific problem.
• Class Organization: Each header file contains exactly one class.
• Encapsulation: Implementation details are hidden as much as possible to reduce coupling.
• Abstraction: All major interfaces are defined as abstract classes.
• Documentation: Every class in the repository is documented.

A SHAMap is a Merkle trie and a radix trie of radix 16. It is used to efficiently compare subtrees or entire trees in O(1) time by comparing hashes. This structure is used to manage transactions (with or without metadata) or account states.

A SHAMap consists of two node types:

• SHAMapInnerNode: Non-leaf nodes that carry the hashes of their children.
• SHAMapLeafNode: Leaf nodes that carry the actual data.

All nodes inherit from SHAMapTreeNode. Nodes are managed via shared_ptr to allow multiple SHAMap instances to share ownership of the same nodes (e.g., when creating snapshots).

The XRPL server provides a continuous stream of fully-validated ledgers to clients.

• Stream Continuity: The server maintains a continuous stream unless it falls too far behind. If it loses sync, it jumps to the current fully-validated ledger and then attempts to resume the stream.
• Backfilling: If the publication is not caught up, the server may attempt to backfill history by retrieving missing ledgers (starting with the highest sequence number) to update the list of resident ledgers.

The Negative UNL (Unique Node List) protocol allows the network to manage unreliable validators by maintaining a list of validators that should not be counted toward ledger validation.

Key concepts:

• Effective UNL: The original UNL minus the Negative UNL.
• Effective Quorum: The quorum calculated from the Effective UNL, defined as Ceiling(80% of effective UNL).
• Validator Behavior: Validators in the Negative UNL still participate in consensus and publish messages, but their validation messages are not counted when verifying if a ledger is fully validated.
• Safety Mechanism: To prevent network instability, the effective quorum is calculated as Ceiling(max(60% * original UNL, 80% * effective UNL)) to ensure it never drops below 60% of the original UNL.

The RCL Consensus directory provides the necessary types and classes to bridge the generic consensus algorithm with the xrpld-specific consensus implementation. The following components are used for this adaptation:

• RCLCxTx: Adapts a SHAMapItem transaction.
• RCLCxTxSet: Adapts a SHAMap to represent a set of transactions.
• RCLCxLedger: Adapts a Ledger.
• RCLConsensus: Implements the requirements of the generic Consensus class by connecting it to the rest of the xrpld application.