The XRP Ledger is a shared, global ledger that is open to all. Individual participants can trust the integrity of the ledger without having to trust any single institution to manage it. The rippled server software accomplishes this by managing a ledger database that can only be updated according to very specific rules. Each instance of rippled keeps a full copy of the ledger, and the peer-to-peer network of rippled servers distributes candidate transactions among themselves. The consensus process determines which transactions get applied to each new version of the ledger. See also: The Consensus Process.

Diagram: Each ledger is the result of applying transactions to the previous ledger version.

The shared global ledger is actually a series of individual ledgers, or ledger versions, which rippled keeps in its internal database. Every ledger version has a Ledger Index which identifies the order in which ledgers occur. Each closed ledger version also has an identifying hash value, which uniquely identifies the contents of that ledger. At any given time, a rippled instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus. Only the validated ledgers are certain to be correct and immutable.

A single ledger version consists of several parts:

Diagram: A ledger has transactions, a state tree, and a header with the close time and validation info

  • A header - The Ledger Index, hashes of its other contents, and other metadata.
  • A transaction tree - The transactions that were applied to the previous ledger to make this one. Transactions are the only way to change the ledger.
  • A state tree - All the ledger objects that contain the settings, balances, and objects in the ledger as of this version.

Tree Format

As its name might suggest, a ledger's state tree is a tree data structure. Each object in the state tree is identified by a 256-bit object ID. In JSON, a ledger object's ID is the index field, which contains a 64-character hexadecimal string like "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94". Every object in the state tree has an ID that you can use to look up that object; every transaction has an indentifying hash that you can use to look up the transaction in the transaction tree. Do not confuse the index (ID) of a ledger object with the ledger_index (sequence number) of a ledger.

Tip: Sometimes, an object in the ledger's state tree is called a "ledger node". For example, transaction metadata returns a list of AffectedNodes. Do not confuse this with a "node" (server) in the peer-to-peer network.

In the case of transactions, the identifying hash is based on the signed transaction instructions, but the contents of the transaction object when you look it up also contain the results and metadata of the transaction, which are not taken into account when generating the hash.

See Also

For more information about ledger headers, ledger object IDs, and ledger object types, see Ledger Data Formats