Rippled Audit

Project Layout

The top level rippled project directory consists of the following dirs & files:

  • bin - misc utility and helper scripts, many legacy or old
  • Builds - build instructions and configurations for CMake, VisualStudio, Linux, MacOS
  • cfg - example rippled service configuration files
  • docs - developer documentation and code standards
  • src - main project source code and vendored modules
  • CMakeLists.txt - entry point for CMake based build system
  • / / LICENSE - Top level docs & legal text

Vendored Deps

Underneath src/ we see the following vendored dependencies:

  • ./src/ripple/beast - HTTP and WebSocket built on Boost.Asio in C++11
  • ./src/ed25519-donna - Implementations of a fast Elliptic-curve Digital Signature Algorithm
  • ./src/lz4 - Extremely fast compression algorithm
  • ./src/nudb - NuDB: A fast key/value insert-only database for SSD drives in C++11
  • ./src/protobuf - Google's data interchange format. Language-neutral, platform-neutral, extensible mechanism for serializing structured data.
  • ./src/rocksdb2 - A Persistent Key-Value Store for Flash and RAM Storage
  • ./src/secp256k1 - Optimized C library for EC operations on curve secp256k1
  • ./src/snappy - A fast compressor/decompressor
  • ./src/soci - The C++ Database Access Library
  • ./src/sqlite - SQLite3 DataBase

The included upstream versions/commits these vendored dependencies are based off of are as follows:

  • beast - custom build
  • ed25519-donna - commit 04223b04e22f5eff32c6c27e25194d4d984c6f41 with a few custom patches
  • lz4 - 1.8.0
  • nudb - 1.0.0-b6 with a few custom patches
  • rocksdb2 - 5.8.7
  • protobuf - commit c9f69500b7d8c616ab107ed0748ae8a3754eef0d (between version 2.5.0 and 2.6.0)
  • secp256k1 - commit 547a53d13507b3348d216d82353e0d6a9d8fa974
  • snappy - 1.1.7
  • soci - commit 79e222e3c2278e6108137a2d26d3689418b37544
  • sqlite - 3.21.0

rippled modules

The primary rippled implementation resides under src/ripple which contains the following subdirs:

  • app - Provides overall application binding and lifecycle logic, combining underlying components to provide the primary application interface. Defines the main entry point and top level structures / methods
  • basics - Utility classes and methods
  • conditions - Crypto Conditions RFC implementation
  • consensus - Generic consensus algorithm and interface. Provides general abstract means to implement a consensus process, used by specific implmentations in other rippled modules
  • core - Central scheduling and database logic
  • crypto - Cryptographic encoding/decoding helper logic
  • json - Generic JSON helper logic
  • ledger - Classes and methods around common ledger definitions and operations
  • net - Implementation of base network operations
  • nodestore - NodeObjects and supporting logic, backed by the ledger and database
  • overlay - Logic governing the Peer-To-Peer network of rippled nodes
  • peerfinder - Logic governing the establishment and maintenance of peer connections to form the overlay network
  • proto - protobuf adapter logic
  • protocol - Utility module defining core protocol data types and functions to access/modify them
  • resource - Manages server/cluster load and computational resource consumption
  • rpc - Common Remote Procedure Call handling and scheduling logic
  • server - HTTP and WebSocket server implementation logic
  • shamap - Merkle Tree / Radix Tree Implementation logic, defining base tree structure used by rippled components
  • unity - includes and boilerplate needed to unify source code for build

Note these descriptions aren't exclusive, many subsystems are composed of components split over the various subdirs. That being said exclusive divisions seem to stand.

Unit tests for the modules listed above can be found in the src/tests directory. They are bundled with the rippled executable on build.

Major modules are explored in detail later on in this analysis report. The next section details the mechanism behind the rippled build system.