Configuration files

Configuration Constraints

While operators have the flexibility to customize certain settings, such as adjusting the size of a cache or specifying an Elasticsearch instance, not all configuration values are open for modification. Critical parameters, like the genesis total supply, must remain unchanged to ensure consistency across the network.

Locating Configuration Files

By default, configuration files are situated in the config directory, typically found near the node's executable. To alter these paths, operators can utilize CLI flags available with the node's binary.

Below, you can find an example of what the configuration files look like for the v0.1.0 node.

├── api.toml
├── config.toml
├── economics.toml
├── enableEpochs.toml
├── enableRounds.toml
├── external.toml
├── gasSchedules
│ ├── gasScheduleV1.toml
│ ├── gasScheduleV2.toml
│ ├── gasScheduleV3.toml
│ ├── gasScheduleV4.toml
│ ├── gasScheduleV5.toml
│ ├── gasScheduleV6.toml
│ └── gasScheduleV7.toml
├── genesisContracts
│ ├── delegation.wasm
│ └── dns.wasm
├── genesis.json
├── genesisSmartContracts.json
├── nodesSetup.json
├── p2p.toml
├── prefs.toml
├── ratings.toml
├── systemSmartContractsConfig.toml
├── testKeys
│ ├── delegationWalletKey.pem
│ ├── dnsWalletKey.pem
│ ├── esdtWalletKey.pem
│ └── protocolSustainabilityWalletKey.pem
└── upgradeContracts
    └── dns
        └── v3.0
            ├── deploy.json
            └── dns.wasm

Blockchain Configuration Files Overview

This document provides an overview of various configuration files used in a blockchain setup. Each file serves a specific purpose, ranging from system smart contracts settings to peer-to-peer network configurations.

systemSmartContractsConfig.toml

Contains configurable values for System Smart Contracts, including parameters for Staking, ESDT, and Governance.

ratings.toml

Holds the parameters used for the nodes' rating mechanism, such as the starting rating and decrease steps.

prefs.toml

Stores a set of custom configuration values that should not be replaced from one upgrade to another.

p2p.toml

Includes peer-to-peer configurable values, such as the number of peers to connect to.

nodesSetup.json

Maintains all the Genesis nodes' public keys, alongside their wallet addresses.

genesisSmartContracts.json

Specifies the Smart Contracts to be deployed at Genesis time, alongside additional parameters.

genesis.json

Contains all the addresses and their balance/active delegation at the genesis.

genesisContracts

Is the directory that contains the WASM contracts deployed at the genesis.

gasSchedules

The directory holding the gas consumption configuration to be used for Smart Contract execution, depending on activation epochs specified in enableEpochs.toml under GasSchedule -> GasScheduleByEpochs.

external.toml

Contains external drivers' configurations, such as Elasticsearch or event notifier.

enableRounds.toml

Lists new features or bug fixes and their activation epoch. (Note: Duplicate with enableEpochs.toml; verify the actual usage in the system.)

enableEpochs.toml

Lists new features or bug fixes and their activation epoch.

economics.toml

Contains the economics configuration, such as genesis total supply, inflation per year, developer fees, etc.

config.toml

Contains the main configuration of the node, including storers & cachers type and size, type of hasher, type of marshaller, etc.

api.toml

Contains the Rest API endpoints configuration, detailing open or closed endpoints, logging, and so on.

Overriding config.toml values​

As mentioned in the above descriptions, prefs.toml is not overwritten by the installation scripts when performing an upgrade.

However, there are some more custom values that nodes operators use (antiflood disabled or with fewer constraints, db lookup extension, and so on) and they don't want these values to be changed during an upgrade.

For this use-case, release v1.4.x introduces the OverridableConfigTomlValues setting inside prefs.toml that is able to override certain configuration values from config.toml.

Here's how to use it:

   OverridableConfigTomlValues = [
     { Path = "StoragePruning.NumEpochsToKeep", Value = "4" },
     { Path = "MiniBlocksStorage.Cache.Name", Value = "MiniBlocksStorage" }
   ]

Therefore, after each upgrade, the node will override these values to the newly provided values. The path points to an entry in config.toml file before setting a new overridable value.