Description of the node configuration file parameters and sections¶
Several types of values are used for parameters in the configuration file:
Integer data which used to specify the exact number of elements. It can be the number of transactions, blocks or connections.
Integer data including measuring units to specify the time periods or memory volume. You typically specify the time periods in days, hours, or seconds, or the cache memory volume, for example,
memory = 256Mor
connection-timeout = 30s.
String which used to specify the addresses, directory paths, passwords and so on. The directory path is specifying in the acceptable format of your current OS and the value is quoted.
Array for the list of values like addresses or public keys. The value is specified in square brackets separated by commas.
yeswhich used for option activation.
An example of the node configuration file is represented on the configuration files prepare page. It includes the following sections:
node - general section, which includes all sections of blockchain settings.
synchronization.transaction-broadcaster - synchronization parameters settings for sending unconfirmed transactions to the blockchain.
additional-cache - configuring additional cache memory settings for temporary storage of incoming blocks.
loggers - detailed configuration of loggers.
ntp - NTP server parameters settings.
blockchain - common blockchain settings.
features - network settings.
tls - enabling and setting up of the node TLS.
network - network settings.
wallet - settings of the private keys access.
miner - mining settings.
rest-api - REST API/gRPC settings and authorization type.
privacy - confidential information access groups settings.
docker-engine - Docker smart contracts settings.
Additional section parameters:
waves-crypto- cryptography type in the blockchain. Possible values:
yes- Waves cryptography,
no- GOST cryptography.
directory- the main directory for the storage of the node software.
data-directory- a directory for storing blockchain data in RocksDB: blocks, transactions, state nodes.
logging-level- logging level. Possible values:
ERROR, default value is
owner-address- the node address, the future owner of the configuration file.
max-batch-time– technical parameters that allow you to adjust the speed of reducing the transaction queue.
min-broadcast-count– a minimum number of connections that can be used to send each transaction to the blockchain. The value should not exceed the number of nodes in the network minus one (the sender should not be taken into account).
retry-delay– an interval for resending a transaction if the number of current connections was not enough, or errors occurred during sending.
extension-batch-size- a number of blocks in the series used to request an extension from peers.
known-tx-cache-size- the maximum number of unconfirmed transactions in the cache.
known-tx-cache-time- the maximum lifetime of unconfirmed transactions in the memory cache.
rocksdb- RocksDB database parameters:
max-cache-size- the maximum cache size.
max-rollback-depth-the number of blocks that the node can be manually rolled back.
remember-blocks-interval-in-cache- a storing period for blocks in the cache.
block-ids- cache parameters for incoming blocks.
max-size- maximum size of the cache.
expire-after- a period, after which stored blocks will be deleted.
This section is intended for listing loggers with an individually set of a logging level. You can find out the list of loggers by using the GET /node/logging method. Loggers are specified as follows:
"com.wavesplatform.mining.MinerImplPoa": TRACE "com.wavesplatform.utx.UtxPoolImpl": DEBUG
server- an NTP server addresses list. The recommended value is
[ «0.pool.ntp.org», «1.pool.ntp.org», … «10.pool.ntp.org» ].
request-timeout- the timeout of the one request to an NTP server. The recommended value is 10 seconds.
expiration-timeout- the timeout of the NTP server requests synchronization. The recommended value is 1 minute.
fatal-timeout- the timeout of the connection to an NTP server. The recommended value is 1 minute.
type- the blockchain type. Possible values are
MAINNETvalue allows you to use the genesis block, consensus and Mainnet settings. When you select
MAINNETin the configuration file of the node which connects to the Mainnet network, you do not need to specify the parameters of
enabled- the option of using fees for the transaction release. Possible values are
address-scheme-character- the address feature character which is used to prevent mixing up addresses from different networks. For the “Waves Enterprise Mainnet” -
Vand for the “Waves Enterprise Partnernet” -
P. You can use any letter you like for the sidechain or test versions of the Waves Enterprise blockchain platform. Nodes must have the same network byte on the same blockchain network.
functionality- main blockchain settings.
genesis- genesis block settings.
feature-check-blocks-period- the blocks period for feature checking and activation.
blocks-for-feature-activation- the number of blocks required to accept feature.
pre-activated-features- a set of blockchain options.
average-block-delay- an average delay between the blocks creation. This parameter is used only for the PoS consensus.
initial-base-target- an initial base number for the managing the mining process. This parameter is used for the PoS consensus . The frequency of the block creation depends on the parameter value therefore the higher the value, the more often blocks are created. Also, the value of the miner’s balance affects the use of this parameter in mining - the larger the miner’s balance, the less the value of
initial-base-targetis used. When setting a value for this parameter, it is recommended to take into account the combination of miners balances and the expected interval between blocks.
block-timestamp- a time and data code. The time is specified in milliseconds and the value must consist of 13 digits. If you specify the standard value
timestampconsisting of 10 digits, then you need to add any three digits at the end.
initial-balance- an initial balance in smallest units. The parameter value affects on the mining process with the PoS consensus. The larger the miner’s balance, the smaller the
initial-base-targetvalue is used for the mining node determination for the current round.
genesis-public-key-base-58- the public key hash of the genesis block, encrypted in Base58.
signature- the genesis block signature, encrypted in Base58.
transactions- a list of network participants with an initial balance, the creation of which will be included in the genesis block.
network-participants- a list of network participants with specified roles, the creation of which will be included in the genesis block.
This section is dedicated to the node TLS.
type- TLS mode status. Possible options:
DISABLED(disabled, in this case other options should be excluded or commented) and
EMBEDDED(enabled, the certificate is signed by a node provider and packed within a JKS file (keystore); the certificate directory and keystore access parameters should be stated by a user in the fields below).
keystore-path- keystore relative path within the node directory:
keystore-password- the password for the generated keystore.
password- a password for the private keys file access.
In order to work with the node TLS, apart its configuration in the node config file, a user should get a keystore file itself with the use of the keytool utility:
keytool \ -keystore we.jks -storepass 123456 -keypass 123456 \ -genkey -alias we -keyalg RSA -validity 9999 \ -dname "CN=Waves Enterprise,OU=security,O=WE,C=RU" \ -ext "SAN=DNS:welocal.dev,DNS:localhost,IP:188.8.131.52,IP:127.0.0.1"
keystore- keystore file name.
storepass- keystore password, which should be stated in the
keystore-passwordsection of the node config file.
keypass- private key password, which should be stated in the
private-key-passwordsection of the config file.
alias- an alias name (upon a user decision).
keyalg- keypair generation algorithm.
validity- keypair validity time in days.
dname- distinguished name according to the X.500 standard, connected with the keystore alias.
ext- extensions that are used for key generation, all possible host names and IP addresses should be stated for work in different networks.
As a result of the keytool utility execution, the keystore file with the filename we.jks will be obtained. In order to connect with the node operating with the TLS, a user should also generate a client certificate:
keytool -export -keystore we.jks -alias we -file we.cert
The obtained certificate file we.cert should be imported into the trusted certificate storage. If the node is located in one network with a user, it will be enough to state a relative path to the we.jks file in the node config file, as demonstrated above.
In case the node is located in another network, a we.cert certificate file should be imported into the keystore:
keytool -importcert -alias we -file we.cert -keystore we.jks
After that, state the relative path to the we.jks file in the node config file.
bind-address- the node network address.
port- the port number.
known-peers- a list of known nodes network addresses. This parameter should be filled in. The list of addresses is passed to the user by the network administrator before the new node is connected.
declared-address- a string with IP address and port to send as external address during the handshake.
max-simultaneous-connections- a maximum number of simultaneously supported connections. This parameter is limited by the number of nodes in the blockchain, i.e. the maximum number of simultaneous connections will not exceed the number of nodes in the network.
peers-request-interval- an interval for requesting a list of peers. The value is specified in seconds or minutes. The recommended value is 1-2 minutes.
attempt-connection-delay- a request interval to connect to any of the known peers.
file- a path to the private keys storage.
password- a password for the private keys file access.
enable- a miner option activation.
quorum- required number of connections (both incoming and outgoing) to attempt block generation. Setting this value to
0enables offline generation. When you are specifying the value, it is necessary to consider that the own mining node is not summed with the parameter value, i.e., if it is
quorum = 2, then you need at least 3 mining nodes in the network.
interval-after-last-block-then-generation-is-allowed- enable block generation only if the last block is not older the given period of time.
micro-block-interval- an interval between microblocks.
min-micro-block-age- a minimal age of the microblock.
max-transactions-in-micro-block- a maximum number of transaction in the microblock.
minimal-block-generation-offset- a minimal time interval between blocks.
supported- a list of supported options.