Stellar is a decentralized, federated peer-to-peer network that allows people to send payments in any asset anywhere in the world instantaneously, and with minimal fee.
Stellar-core is the core component of this network.
Stellar-core is a C++
implementation of the Stellar Consensus Protocol configured to construct a chain
of ledgers that are guaranteed to be in agreement across all the participating
nodes at all times.
For more detail on the Stellar Consensus Protocol and how it establishes this
- Building & Installing
- Stellar-core administration
- Key Concepts
- Integration with other services
- Major Components
- Supporting Code Directories
There are a few major components of the system. Each component has a dedicated
source directory and its own dedicated
SCP is our implementation of the Stellar Consensus Protocol (SCP). This component is fully abstracted from the rest of the system. It receives candidate black-box values and signals when these values have reached consensus by the network (called externalizing a value) (See
Herder is responsible for interfacing between SCP and the rest of
stellar-core. Herder provides SCP with concrete implementations of the methods SCP uses to communicate with peers, to compare values, to determine whether values contain valid signatures, and so forth. Herder often accomplishes its tasks by delegating to other components (See
Overlay connects to and keeps track of the peers this node knows about and is connected to. It floods messages and fetches from peers the data that is needed to accomplish consensus (See
src/overlay/readme.md). All other data downloads are handled without imposing on the SCP-nodes, see
Ledger applies the transaction set that is externalized by SCP. It also forwards the externalization event to other components: it submits the changed ledger entries to the bucket list, triggers the publishing of history, and informs the overlay system to update its map of flooded messages. Ledger also triggers the history system's catching-up routine when it detects that this node has fallen behind of the rest of the network (See
History publishes transaction and ledger entries to off-site permanent storage for auditing, and as a source of catch-up data for other nodes. When this node falls behind, the history system fetches catch-up data and submits it to Ledger twice: first to verify its security, then to apply it (See
BucketList stores ledger entries on disk arranged for hashing and block-catch-up. BucketList coordinates the hashing and deduplicating of buckets by multiple background threads (See
Transactions implements all the various transaction types (See src/transactions/readme.md).
Supporting Code Directories
src/main handles booting, loading of the configuration and of persistent state flags. Launches the test suite if requested.
src/crypto contains standard cryptographic routines, including random number generation, hashing, hex encoding and Stellar Key encoding.
src/util gathers assorted logging and utility routines.
src/lib keeps various 3rd party libraries we use.
src/database is a thin layer above the functionality provided by the database-access library
src/process is an asynchronous implementation of
system(), for running subprocesses.
src/simulation provides support for instantiating and exercising in-process test networks.
src/xdr contains to definition of the wire protocol in the
XDR(RFC4506) specification language.
src/generated contains the wire protocol's C++ classes, generated from the definitions in