Component overview

The Stellar stack is composed of several key components: Stellar Core, Horizon API, RPC, and the networks. Each element plays a specific role in establishing a financial infrastructure that is resilient to failures, accessible to everyone, and fast and cost-effective enough to support real-world applications.

Stellar Components Overview
Figure 1. Stellar Components Overview

Stellar Core

Stellar Core functions as the software employed by the individual nodes within the network. Its role involves maintaining a unified distributed ledger and facilitating consensus to validate and execute transactions.

Consensus among nodes is achieved through the utilization of the Stellar Consensus Protocol, which is built upon the Federated Byzantine Agreement (FBA) framework.

In SCP, every participating Stellar Core node, also referred to as a validator or validator node, determines the set of other nodes they choose to trust. This user-defined trust flexibility enables an open network membership, allowing anyone to become a Core node, and facilitates decentralized control.

Horizon API

Horizon operates as the client-facing RESTful HTTP API server within the platform layer. It provides programmatic access for submitting transactions and querying the network’s historical data. Serving as the interface for applications seeking to interact with the Stellar network, Horizon can be accessed through various means, including SDKs, web browsers, or straightforward command-line tools like cURL.

Soroban RPC

Soroban’s RPC is a JSON RPC server designed to offer an interface for users and applications to engage with smart contracts on the Stellar blockchain. When an application seeks to interact with smart contracts, it sends a request to the RPC server. Subsequently, the server interprets these requests, translates them into a format understandable by the blockchain nodes, and forwards them. Upon processing the requests, the blockchain nodes transmit back the results. The RPC server then receives and returns these results to the requesting application.

SDF provides RPC endpoints for Futurenet and Testnet. These services are freely accessible and suitable for development and testing purposes. However, SDF does not offer a publicly accessible RPC endpoint for Mainnet. Developers should select an ecosystem provider that aligns with their project requirements before transitioning to Mainnet. In certain instances, projects may opt to operate their own RPC instance.

Network

Stellar operates on three distinct networks: the public network (Mainnet, also referred to as Pubnet or the Public Network), the test network (Testnet), and a development network (Futurenet).

Mainnet serves as the primary network utilized by applications in production. It connects to real financial systems and necessitates XLM to cover minimum balances, transaction fees, and rent.

Testnet, on the other hand, is a smaller, freely accessible network maintained by SDF. It closely resembles Mainnet in functionality but does not involve real money transactions. Testnet features a built-in testnet XLM faucet, known as Friendbot, and undergoes periodic resets. As a result, it provides developers with a stable environment for testing applications.

Futurenet operates as a development network suitable for testing cutting-edge features. Similar to Testnet, it includes its own Friendbot and undergoes resets as needed. However, Futurenet’s resets are less predictable compared to Testnet. It serves as a platform for introducing new features before they are implemented in stable releases.

Node

Every node within the Stellar network carries out fundamental tasks: running Stellar Core, establishing connections with peers, submitting transactions, storing the ledger state in a SQL database, and maintaining a duplicate copy of the ledger in flat XDR files known as buckets.

Moreover, nodes can be configured to perform two crucial functions that dictate their behavior:

  • Participate in consensus to authenticate transactions.

  • Publish an archive, which other nodes can reference to access the entire history of the network.

Types of Nodes

Basic Validator

A Basic Validator operates by tracking the ledger and submitting transactions for potential inclusion, although it isn’t configured to publish history archives publicly. While it necessitates a secret key, it’s set up to engage in consensus by voting on and endorsing changes to the ledger, thus contributing to network support and decentralization. The primary benefit lies in its ability to provide real-time endorsements of specific ledgers through its signatures. This feature proves invaluable, especially when dealing with assets on Stellar representing real-world assets. By informing customers that transactions and asset redemptions will only be honored based on ledgers endorsed by the validator, one can establish trust and transparency. Moreover, in rare instances where network disruptions occur, the node can serve as the final authority on truth. Setting up the node as a validator offers upfront resolution to potential disputes or disasters. The usage of a Basic Validator is to ensure dependable network access and sign off on transactions.

Full Validator

A Full Validator operates similarly to a Basic Validator but with an additional crucial function: publishing a History Archive that contains comprehensive snapshots of the ledger, including all transactions and their outcomes. Unlike Basic Validators, Full Validators write to an internet-accessible blob store, such as AWS or Azure. While this setup incurs higher costs and complexity, it significantly enhances the network’s resilience and decentralization. When new nodes join the network or encounter synchronization issues, they can rely on archives provided by Full Validators to catch up on the network’s history. The presence of redundant archives mitigates the risk of a single point of failure and empowers network participants to verify the accuracy of historical data. The usage of a Full Validator is to sign off on transactions and to contribute to the robustness and decentralization of the network.

Archiver

An Archiver, while rare, serves a unique role similar to a Full Validator in publishing the network’s activity for long-term storage. However, unlike a Full Validator, an Archiver does not engage in consensus activities. Although Archivers contribute to decentralization by providing redundant records of the network’s history, they do not vote or sign ledgers. As a result, their utility is somewhat restricted compared to Full Validators.