Stellar is a network that is decentralized with multiple nodes that comprise computers that maintain a distributed ledger that is shared. The nodes interact with each with the intention of validating and adding transaction to ledger. Stellar Core is an implementation of the Stellar Consensus Protocol. Nodes utilize it to remain in sync when working on verifying transactions and transferring their data to the ledger.

Different types of nodes

Every Stellar nodes’ fundamental functions are similar they all run Stellar Core and making connections to other peers processing transactions as well as storing the ledger’s information in an SQL databases, as well as maintaining copies of ledger data in flat XDR buckets. Horizon represents an instance of Stellar API that is supported by all nodes. In addition to the basic functions two crucial settings determine the behavior of a given node. A node may:

• Participate in consensus on transitions validation
• They also publish the archive, which other networks may browse to discover the entire background of the entire network.

On the basis of these two important points, nodes can be classified in four different types:

1. Watcher
2. Basic Validator
3. Full Validator
4. Archiver

All kinds of nodes are compatible with Horizon and can submit transactions to the network. The differentiator is in the process of validating transactions and publishing the history.

1. Watcher

A Watcher maintains track of the ledger and makes transactions, however it’s not equipped to participate in the validation of transactions or to publish an archived history of transactions. This means that a watcher does not contribute anything to the network or improve the decentralization. It’s the lightest node. Watcher works well with Horizon and, if the need is just for a Horizon for instance then a Watcher is the ideal option.

2. Basic Validator

A Basic validator is a basic one with similar operational requirements and offers the same advantages to Watcher. The main difference in the Basic validator is that Basic validator is secured with the secret key and can be configured to join the consensus.

3. Full Validator

As with the Basic validator The Full Validator accomplishes the same tasks, except that it also creates an archive of history that contains some of the entries in the ledger. Although it’s expensive and difficult to use but it is a great tool for enhancing its network’s resilience as well as decentralization. New nodes joining the network or have a short time of being out of sync may look through the archives of Full validators to keep up on the history of the network.

Full validator is also able to assist with Horizon however, the companies which run them do not use them to access network data or make transactions. Instead, they prefer to use Watcher alongside Full Validator to handle Horizon.

4. Archiver

As a Full validator an archiver reports on the events of the network, but isn’t a part of consensus. Its use is comparatively restricted. If the goal is running a Stellar-compatible application like blockchain explorer, archives must be running. Utilize an archiver when you need to use the network as a reference that is not likely.

Environment set-up

There are a variety of methods for installing Stellar Core. Once installed, it can be programmed to join the network at various levels such as Watcher, Basic Validator and Full Validator. However, regardless of how Stellar Core is installed, it’s essential in order to be connected to a peer-to -peer network, record the ledger’s data in the database, and join Stellar API, Horizon. Stellar API, Horizon.

• Calculate the requirements

Stellar Core PostgreSQL works well on an m5.large in AWS with twin-core 2.5GHz Intel Xenon and 8GB RAM. Storage-wise, 1TB of storage space is considered as a minimum. In the event that Stellar Core is running in combination with Horizon make sure that the system configuration is ready to meet the needs of Horizon’s computing requirements.

• Access to the network

Stellar Core connects to a peer-to peer network to keep the ledger up-to-date. This means that the node has to keep certain TCP ports open for both communication inbound and outbound.

Inbound Stellar Core node allows all IPs to connect to its PEER_PORT using TCP. Ports can be defined when configuring Stellar Core, but the default port (11625) is the most commonly used.

Outbound Stellar Core needs to connect to other nodes using PEER_PORT via TCP. Details about other nodes PEER_PORT may be located on a network explorer like Stellarbeat.

Install Stellar Core

Installers can use Stellar Core in three ways using an image from Docker built from pre-built packages or build directly from sources. In this article, the two first methods are described; installing from source will require building instructions.

• Installing Docker using the Docker protocol:

SDF maintains a quickstart image that includes Stellar Core with PostgreSQL database and Horizon. It’s an easy method to create an ephemeral, non-validating configuration that is compatible with the majority of developers. SDF also manages Stellar Corre as a standalone image that creates a three node local Stellar Core network, all hosted on the same Docker host. Furthermore, SatoshiPay maintains Docker’s separate image for Horizon and Stellar Core. It comes in a variety of variants, such as one with AWS CLI running as well as one that comes with Google Cloud SDK installed.

• Installation based on packages :

for Ubuntu 16.40 LTS customers There’s Stellar Core and Horizon’s latest version with Debian Binary package formats. These packages are installed separately, allowing the greatest flexibility, but not requiring manual configuration files or an PostgreSQL database. There is also you can install an excellent quickstart package is also available. It sets up the Testnet Stellar Core and Horizon that are both supported by the Local PostgreSQL database. It is also able to be altered after it is installed.

Configuration

After installation, the following step is to create an configuration file that explains crucial information about the nodes such as the database they write to and whether it is connected to a public network or testnet, and what other nodes are part of the Quorum Set. This is accomplished by using TOML. By default, stellar core loads the file from ./stellar-core.cfg. Another file may be loaded by using the command:

1. Database

Stellar Core has two copies of the ledger. One in an SQL database, and the second in XDR files stored on local disks referred to as buckets. In the event of consensus it is the database that is checked and changed automatically whenever a transaction set is added in the ledger. It’s quick, precise and has random access.

2. Buckets

Stellar Core stores a copy of the ledger in flat XDR files, referred to as buckets. These files are kept in the directory defined within the configuration files, which is named BUCKET_DIR_PATH that is the default setting for buckets. Bucket files perform the hashing, as well as transmitting ledger changes to archives from the past. Rapid local disks that have sufficient space are needed for storing buckets. For the most part the contents of buckets and databases is handled via Stellar Core to be ignored. When you run Stellar Core on the first occasion, you must initialize buckets and databases with these commands.

Read More: https://www.leewayhertz.com/run-stellar-core-node/