HOW TO SETUP AND RUN STELLAR CORE NODE?
Stellar is a network that is decentralized with multiple nodes that are computers that manage an open ledger. The nodes interact with each with the intention of validating and adding entries to the ledger. Stellar Core is an implementation of the Stellar Consensus Protocol. Nodes make use of it to remain in sync when working on the validation of transactions and then applying their data to the ledger.
Nodes of different types
The majority of Stellar nodes' primary functions are similar that is running Stellar Core and communicating with peers, managing transactions as well as storing the ledger's information in an SQL databases, as well as maintaining copies of the ledger's state in flat XDR buckets. Horizon can be described as an instance of Stellar API that is supported by all nodes. In addition to the basic functions two crucial configuration options affect the behavior of a given node. A node could:
- Participate in consensus on transitions validation
- Create archives that nodes are able to browse to discover the entire timeline of network activities.
On the basis of these two crucial points, nodes can be classified into four categories:
- Watcher
- Basic Validator
- Full Validator
- Archiver
All kinds of nodes are compatible with Horizon and allow transactions to be submitted to the network. The differentiator is in the process of validating transactions and publishing their history.
- Watcher
A Watcher maintains track of the ledger and makes transactions, but it's not equipped to participate in the validation of transactions or to publish an archived history of transactions. This means that a Watcher can't contribute anything to the network or boost the decentralization. It's the lightest node. Watcher is compatible with Horizon and if your requirement is just for a Horizon for instance it is the ideal option.
2. Basic Validator
Basic Validators have the same functional requirements and has the same advantages to Watchers. The main difference in the Basic validator is that Basic validator has the secret key and can be configured to join the consensus.
3. Full Validator
As with the Basic validator The Full Validator does the same functions, with the exception that it also creates an archive of all the snapshots of ledgers. Although it's expensive and difficult to use however, it helps its network's resilience as well as decentralization. New nodes joining the network or have a short time of being out of sync may access archives maintained by Full validators to keep up with the history of the network.
Full validator may also be able to support Horizon however, the companies who run them don't utilize the tools to request information from networks or to submit transactions. Instead, they prefer to use Watcher alongside Full validator in order to manage Horizon.
4. Archiver
As a Full validator an archiver reports on the actions of the network, however it doesn't take part in consensus. Its utility is restricted. If you want for Stellar to be able to host a program like blockchain explorer, archives will need to be running. You can use an archiver if need to use the network as a reference that is not likely.
Environment setting Up
There are a variety of methods for installing Stellar Core. After installation, it is able to be programmed to join the network on different levels that include Watcher, Basic Validator as well as Full validateator. Whatever way the Stellar Core is installed, it's necessary in order to be connected to a peer-to -peer network, record the ledger's data in the database, and access Stellar API, Horizon. Stellar API, Horizon.
- Determine the requirements
Stellar Core PostgreSQL works well on an m5.large in AWS that has two-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 able to handle the requirements of Horizon's computation.
- Access to the network
Stellar Core connects to a peer-to-peer network in order to ensure that the ledger is in sync. This means that the node has to keep certain TCP ports open for both outbound and inbound communications.
The 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. Information on other nodes PEER_PORT may be obtained from a network browser like Stellarbeat.
Install Stellar Core
Installers can use Stellar Core in three ways that include using Docker images built from pre-built packages or build directly from sources. In this article, the two first methods are described; installing from source requires build instructions.
- Installation using Docker: SDF maintains a quickstart image that integrates Stellar Core with PostgreSQL database and Horizon. It's a simple method to create an ephemeral configuration with no validation that is compatible with the majority of developers. SDF also supports Stellar Corre the only image that is standalone which starts a three-node local Stellar Core network, all running on the same docker host. Furthermore, SatoshiPay maintains Docker's separate image for Horizon and Stellar Core. It is available in several versions, with one having AWS CLI as well as one that comes with Google Cloud SDK installed.
- Installation based on packages: for Ubuntu 16.40 LTS owners There's Stellar Core and Horizon's latest version with Debian Binary package formats. The packages can be installed separately, allowing the most amazing flexibility, however not requiring manual configuration files or an PostgreSQL database. But, you can install an excellent quickstart package is also available. It sets up an Testnet Stellar Core and Horizon which are both supported by the locally-based PostgreSQL database. The package can also be changed after it is installed.
Configuration
After installation, the following step is to finish the configuration file which outlines essential information about the nodes, such as what 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 using TOML. By default, stellar core loads the file from ./stellar-core.cfg. Another file may be loaded with the command:
1. Database
Stellar Core has two copies of the ledger, one in an SQL database, and the second in XDR files that reside on local disks, referred to as buckets. When there is consensus it is the database that is automatically consulted and updated whenever a transaction set is added on the ledger. It's fast, precise and has random access.
2. Buckets
Stellar Core stores a copy of the ledger in flat XDR files, also known as buckets. These files are kept in the directory defined by the file configuration, which is named BUCKET_DIR_PATH and is the default setting for buckets. The bucket files are used for hashing and transmit ledger changes to archives from the past. Local disks that are fast and have enough space are required for storing buckets. But, for the majority of instances the contents of buckets and databases is handled through Stellar Core to be ignored. When you run Stellar Core on the first occasion, you must initialize buckets and databases using this command.
Read More : https://www.leewayhertz.com/run-stellar-core-node/
Comments
Post a Comment