Preparation of configuration files¶
These following configuration files are used for the configuration:
accounts.conf
– the configuration file for the accounts creation.api-key-hash.conf
– the configuration file for theapi-key-hash
andprivacy-api-key-hash
values creation when you choose theapi-key
string hash authorization.node.conf
– the main node configuration file defining the operational principals and an option list.
accounts.conf
configuration file for the accounts creation¶
When specifying a path, use the “forward slash” - /
as a delimiting character for directory hierarchy levels. During Linux using the value wallet
must match the directory structure of the operating system, for example /home/contract/we/keystore.dat
. During node setting it is prohibited to use cyrillic symbols for specifying paths to the working directory, keystore, etc.
// accounts.conf listing
accounts-generator {
waves-crypto = yes
chain-id = V
amount = 1
wallet = ${user.home}"/node/keystore.dat"
wallet-password = "some string as password"
reload-node-wallet {
enabled = false
url = "http://localhost:6862/utils/reload-wallet"
}
}
The description of the configuration file parameters is represented below.
waves-crypto
– the choice of a cryptographic algorithm (“yes” - use cryptography Waves, “no” - use GOST-cryptography);
chain-id
– an identifying byte of the network, the value will be necessary further on for entry in parameteraddress-scheme-character
of the node configuration file;
amount
– a number of generated key pairs;
wallet
– the path to the key storage directory on the node, the value will be required further on for entry in parameterwallet > file
of the node configuration file. For the Waves cryptography, the path to filekeystore.dat
is specified (example,${user.home}/nodeName/keystore.dat
), for the GOST-cryptography - the path to directory (${user.home}/nodeName/keystore/
);
wallet-password
– a password for access to closed node keys, the value will be necessary further for entry into the parameterwallet > password
of the node configuration file;
reload-node-wallet
– an option to update the node keyStore without restarting the application, by default it is turned off (false
).url
parameter specifies the path to the/utils/reload-wallet
method of the REST API node.
api-key-hash.conf
configuration file¶
api-key-hash.conf
configuration file is intended only for the api-key-hash
and privacy-api-key-hash
values creation when you choose the api-key
string authorization.
// api-key-hash.conf listing
apikeyhash-generator {
waves-crypto = yes
api-key = "some string for api-key"
}
Parameters description
waves-crypto
– the choice of a cryptographic algorithm (“yes” - use cryptography Waves, “no” - use GOST-cryptography);
api-key
– the key you need to come up with. The value of this key will need to be specified in requests to REST API node (for more details see page REST API).
node.conf
node configuration file¶
Если планируется подключение к существующей сети, то для упрощения подключения запросите готовый конфигурационный файл ноды у одного из участников сетевого взаимодействия или у администратора вашей сети. При создании сети с нуля или подключении к сети “Waves Enterprise Mainnet” пример конфигурационного файла ноды можно взять на странице проекта на GitHub.
Файл node.conf
выполнен в формате HOCON.
Об изменениях в конфигурационном файле ноды можно почитать в разделе Изменения в конфигурационном файле ноды.
Warning
If your node’s version is 1.0 and higher you need to specify the following parameter in the node
section of the node configuration file:
"features": {
"supported": [100]
}
This option becomes active when the total quantity of blocks from feature-check-blocks-period = 15000
and blocks-for-feature-activation = 10000
parameters is achieved (25 000 of blocks). These parameters are stored in the blockchain
section and can not be changed during Mainnet or Partnernet connection. Nodes will not be able to connect to the network without activation of this option.
The example of the node configuration file is represented below. This file does not include such options like anchoring, Docker smart contracts and private data access groups. Also enabling of the sender
role in the genesis
block is demonstrated.
Attention
Генезис - это первый блок сети, от которого формируется блокчейн. Для включения роли sender
необходимо явно указать версию генезиса (2), а также добавить сам параметр включения роли. Описание роли sender
см. в разделе Управление полномочиями.
The ``api-key` key string hash authorization, as well as the Waves cryptography are also demonstrated. Description of the node configuration file parameters is available here.
Note
If you want to use additional options, set the enable
field of the selected option to yes
or true
and configure the option section according to the description of its setting.
Warning
Please, fill ONLY the fields with the /FILL/ word inside as a value.
node {
# Type of cryptography
waves-crypto = yes
# Node owner address
owner-address = " /FILL/ "
# NTP settings
ntp.fatal-timeout = 5 minutes
# Node "home" and data directories to store the state
directory = "/node"
data-directory = "/node/data"
# Location and name of a license file
# license.file = ${node.directory}"/node.license"
wallet {
# Path to keystore.
file = "/node/keystore.dat"
# Access password
password = " /FILL/ "
}
# Blockchain settings
blockchain {
type = CUSTOM
fees.enabled = false
consensus {
type = "poa"
round-duration = "17s"
sync-duration = "3s"
ban-duration-blocks = 100
warnings-for-ban = 3
max-bans-percentage = 40
}
custom {
address-scheme-character = "E"
functionality {
feature-check-blocks-period = 1500
blocks-for-feature-activation = 1000
pre-activated-features = { 2 = 0, 3 = 0, 4 = 0, 5 = 0, 6 = 0, 7 = 0, 9 = 0, 10 = 0, 100 = 0, 101 = 0 }
}
# Mainnet genesis settings
genesis {
version: 2
sender-role-enabled: true
average-block-delay: 60s
initial-base-target: 153722867
# Filled by GenesisBlockGenerator
block-timestamp: 1573472578702
initial-balance: 16250000 WEST
# Filled by GenesisBlockGenerator
genesis-public-key-base-58: ""
# Filled by GenesisBlockGenerator
signature: ""
transactions = [
# Initial token distribution:
# - recipient: target's blockchain address (base58 string)
# - amount: amount of tokens, multiplied by 10e8 (integer)
#
# Example: { recipient: "3HQSr3VFCiE6JcWwV1yX8xttYbAGKTLV3Gz", amount: 30000000 WEST }
#
# Note:
# Sum of amounts must be equal to initial-balance above.
#
{ recipient: " /FILL/ ", amount: 1000000 WEST },
{ recipient: " /FILL/ ", amount: 1500000 WEST },
{ recipient: " /FILL/ ", amount: 500000 WEST },
]
network-participants = [
# Initial participants and role distribution
# - public-key: participant's base58 encoded public key;
# - roles: list of roles to be granted;
#
# Example: {public-key: "EPxkVA9iQejsjQikovyxkkY8iHnbXsR3wjgkgE7ZW1Tt", roles: [permissioner, miner, connection_manager, contract_developer, issuer]}
#
# Note:
# There has to be at least one miner, one permissioner and one connection_manager for the network to start correctly.
# Participants are granted access to the network via GenesisRegisterNodeTransaction.
# Role list could be empty, then given public-key will only be granted access to the network.
#
{ public-key: " /FILL/ ", roles: [permissioner, sender, miner, connection_manager, contract_developer, issuer]},
{ public-key: " /FILL/ ", roles: [miner, sender]},
{ public-key: " /FILL/ ", roles: []},
]
}
}
}
# Application logging level. Could be DEBUG | INFO | WARN | ERROR. Default value is INFO.
logging-level = DEBUG
tls {
# Supported TLS types:
# • EMBEDDED: Certificate is signed by node's provider and packed into JKS Keystore. The same file is used as a Truststore.
# Has to be manually imported into system by user to avoid certificate warnings.
# • DISABLED: TLS is fully disabled
type = DISABLED
# type = EMBEDDED
# keystore-path = ${node.directory}"/we_tls.jks"
# keystore-password = ${TLS_KEYSTORE_PASSWORD}
# private-key-password = ${TLS_PRIVATE_KEY_PASSWORD}
}
# P2P Network settings
network {
# Network address
bind-address = "0.0.0.0"
# Port number
port = 6864
# Enable/disable network TLS
tls = no
# Peers network addresses and ports
# Example: known-peers = ["node-1.com:6864", "node-2.com:6864"]
known-peers = [ /FILL/ ]
# Node name to send during handshake. Comment this string out to set random node name.
# Example: node-name = "your-we-node-name"
node-name = " /FILL/ "
# How long the information about peer stays in database after the last communication with it
peers-data-residence-time = 2h
# String with IP address and port to send as external address during handshake. Could be set automatically if uPnP is enabled.
# Example: declared-address = "your-node-address.com:6864"
declared-address = "0.0.0.0:6864"
# Delay between attempts to connect to a peer
attempt-connection-delay = 5s
}
# New blocks generator settings
miner {
enable = yes
# Important: use quorum = 0 only for testing purposes, while running a single-node network;
# In other cases always set quorum > 0
quorum = 0
interval-after-last-block-then-generation-is-allowed = 10d
micro-block-interval = 5s
min-micro-block-age = 3s
max-transactions-in-micro-block = 500
minimal-block-generation-offset = 200ms
}
# Nodes REST API settings
api {
rest {
# Enable/disable REST API
enable = yes
# Network address to bind to
bind-address = "0.0.0.0"
# Port to listen to REST API requests
port = 6862
# Enable/disable TLS for REST
tls = no
}
grpc {
# Enable/disable gRPC API
enable = yes
# Network address to bind to
bind-address = "0.0.0.0"
# Port to listen to gRPC API requests
port = 6865
# Enable/disable TLS for gRPC
tls = no
akka-http-settings {
akka {
http.server.idle-timeout = infinite
}
}
}
auth {
type: "api-key"
# Hash of API key string
# You can obtain hashes by running ApiKeyHash generator
api-key-hash: " /FILL/ "
# Hash of API key string for PrivacyApi routes
privacy-api-key-hash: " /FILL/ "
}
}
#Settings for Privacy Data Exchange
privacy {
# Max parallel data crawling tasks
crawling-parallelism = 100
storage {
vendor = none
# for postgres vendor:
# schema = "public"
# migration-dir = "db/migration"
# profile = "slick.jdbc.PostgresProfile$"
# jdbc-config {
# url = "jdbc:postgresql://postgres:5432/node-1"
# driver = "org.postgresql.Driver"
# user = postgres
# password = wenterprise
# connectionPool = HikariCP
# connectionTimeout = 5000
# connectionTestQuery = "SELECT 1"
# queueSize = 10000
# numThreads = 20
# }
# for s3 vendor:
# url = "http://localhost:9000/"
# bucket = "privacy"
# region = "aws-global"
# access-key-id = "minio"
# secret-access-key = "minio123"
# path-style-access-enabled = true
# connection-timeout = 30s
# connection-acquisition-timeout = 10s
# max-concurrency = 200
# read-timeout = 0s
}
cleaner {
enabled: no
# The amount of time between cleanups
# interval: 10m
# How many blocks the data hash transaction exists on the blockchain, after which it will be removed from cleaner monitoring
# confirmation-blocks: 100
# The maximum amount of time that a file can be stored without getting into the blockchain
# pending-time: 72h
}
}
# Docker smart contracts settings
docker-engine {
# Docker smart contracts enabled flag
enable = yes
# For starting contracts in a local docker
use-node-docker-host = yes
default-registry-domain = "registry.wavesenterprise.com/waves-enterprise-public"
# Basic auth credentials for docker host
#docker-auth {
# username = "some user"
# password = "some password"
#}
# Optional connection string to docker host
docker-host = "unix:///var/run/docker.sock"
# Optional string to node REST API if we use remote docker host
# node-rest-api = "node-0"
# Execution settings
execution-limits {
# Contract execution timeout
timeout = 10s
# Memory limit in Megabytes
memory = 512
# Memory swap value in Megabytes (see https://docs.docker.com/config/containers/resource_constraints/)
memory-swap = 0
}
# Reuse once created container on subsequent executions
reuse-containers = yes
# Remove container with contract after specified duration passed
remove-container-after = 10m
# Remote registries auth information
remote-registries = []
# Check registry auth on node startup
check-registry-auth-on-startup = yes
# Contract execution messages cache settings
contract-execution-messages-cache {
# Time to expire for messages in cache
expire-after = 60m
# Max number of messages in buffer. When the limit is reached, the node processes all messages in batch
max-buffer-size = 10
# Max time for buffer. When time is out, the node processes all messages in batch
max-buffer-time = 100ms
}
}
}