Phase overview: Inside rippled
Your map of the Inside rippled phase: architecture and tooling, state and storage, and transaction processing, and how the sixteen modules fit together.
Introduction
≈2 min · Phase overview · read this before diving in
You have a node running; now you open the hood. This phase is the longest of the bootcamp because it builds the mental model everything else hangs on: how the Application object wires seventy subsystems together, how the ledger's state actually lives in memory and on disk, and what happens, function by function, when a transaction is processed.
The phase moves through three arcs. Architecture and tooling first: the Application layer, how to navigate a two-million-line codebase, the full life of a transaction, and the debugging techniques you will reuse in every later module. Then state and storage: the SHAMap (the Merkle-Patricia tree at the heart of everything), the NodeStore, its pluggable backends, and the caching that keeps it all fast. Finally transaction processing: the transactor framework, the preflight/preclaim/doApply pipeline, fees and sequences, the TER result codes, and a line-by-line case study of a real transactor.
The road through this phase
| Module | Duration | What it covers |
|---|---|---|
| Architecture & tooling | ||
| The Application layer | 60 min | How the Application class wires rippled together — the central orchestrator that owns and coordinates eve... |
| Navigating the rippled codebase | 60 min | Find your way around the modern rippled source tree (include/xrpl, src/libxrpl, src/xrpld) and the na... |
| The complete transaction lifecycle | 75 min | Follow a transaction from creation and signing through submission, validation, consensus, canonical applica... |
| Development & debugging techniques | 60 min | The tools and workflows for investigating rippled behaviour — standalone mode, logging, gdb, and inspecting... |
| Protocols & wire messages | 60 min | How rippled nodes talk on the wire — the peer protocol, protobuf message types, and where message handling ... |
| State & storage | ||
| State-management foundations | 60 min | Why blockchain state needs a cryptographic commitment, and the tree / Merkle / Patricia-trie foundations be... |
| SHAMap architecture & hashing | 90 min | The structure of XRPL's SHAMap — inner vs leaf nodes, node types, key-based navigation, and how hashes roll... |
| SHAMap synchronization & proofs | 60 min | How nodes compare and sync SHAMaps by hash, and how compact Merkle proofs let clients verify state without ... |
| NodeStore architecture | 60 min | The pluggable, hash-indexed key-value store that persists SHAMap nodes, and its NodeObjectType model |
| Storage backends & database operations | 60 min | The NodeStore backends (NuDB, RocksDB…) and the fetch / store / batch / async lifecycle above them |
| Caching & resource management | 60 min | The cache layer that keeps hot nodes in memory, and the memory / disk / throughput characteristics of a pro... |
| Transaction processing | ||
| Transactor architecture | 90 min | The Transactor base class and framework — contexts, phases, and how every transaction type extends a shar... |
| The transaction processing pipeline | 30 min | The four-phase validation pipeline (preflight → preclaim → doApply → finalization) and what each phase may ... |
| State modification, fees & sequences | 60 min | How a transactor modifies ledger state through views, and how fees, reserves and sequence numbers are handled |
| TER result codes | 30 min | The Transaction Engine Result taxonomy — tes / tec / ter / tef / tem / tel — and how to choose the right code |
| Case study — the CheckCreate transactor | 45 min | A code-level walkthrough of a real transactor (CheckCreate) across preflight, preclaim and doApply |
Total: about 16 hours of module time, plus your own exploration. The modules are ordered so each builds on the previous one; resist the temptation to skip ahead.
Where you will land
By the end of this phase you can find any subsystem in the codebase, explain how the ledger state is stored and hashed, trace a transaction from submission to its effect on the ledger, and read a transactor the way its authors do. That is the foundation the cryptography, networking, and consensus phases build on.