Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
3 contributors

Users who have contributed to this file

@jakm @martinboehm @wakiyamap
115 lines (99 sloc) 8.91 KB

Configuration

Coin definitions are stored in JSON files in configs/coins directory. They are single source of Blockbook configuration, Blockbook and back-end package definition and build metadata. Since Blockbook supports only single coin index per running instance, every coin (including testnet) must have single definition file.

Because most of coins are fork of Bitcoin and they have similar way to install and configure their daemon, we use templates to generate package definition and configuration files during build process. It is similar to build Blockbook package too. Templates are filled with data from coin definition. Although build process generate packages automatically, there is sometimes necessary see intermediate step. You can generate all files by calling go run build/templates/generate.go coin where coin is name of definition file without .json extension. Files are generated to build/pkg-defs directory.

Good examples of coin configuration are configs/coins/bitcoin.json and configs/coins/ethereum.json for Bitcoin-like coins and different coins, respectively.

Description of coin definition

  • coin – Base information about coin.

    • name – Name of coin used internally (e.g. "Bcash Testnet").
    • shortcut – Ticker symbol (code) of coin (e.g. "TBCH").
    • label – Name of coin used publicly (e.g. "Bitcoin Cash Testnet").
    • alias – Name of coin used in file system paths and config files. We use convention that name uses lowercase characters and underscore '_' as a word delimiter. Testnet versions of coins must have _testnet suffix. For example "bcash_testnet".
  • ports – List of ports used by both back-end and Blockbook. Ports defined here are used in configuration templates and also as source for generated documentation.

    • backend_rpc – Port of back-end RPC that is connected by Blockbook service.
    • backend_message_queue – Port of back-end MQ (if used) that is connected by Blockbook service.
    • backend_* – Additional back-end ports can be documented here. Actually the only purpose is to get them to port table (prefix is removed and rest of string is used as note).
    • blockbook_internal – Blockbook's internal port that is used for metric collecting, debugging etc.
    • blockbook_public – Blockbook's public port that is used to comunicate with Trezor wallet (via Socket.IO).
  • ipc – Defines how Blockbook connects its back-end service.

    • rpc_url_template – Template that defines URL of back-end RPC service. See note on templates below.
    • rpc_user – User name of back-end RPC service, used by both Blockbook and back-end configuration templates.
    • rpc_pass – Password of back-end RPC service, used by both Blockbook and back-end configuration templates.
    • rpc_timeout – RPC timeout used by Blockbook.
    • message_queue_binding_template – Template that defines URL of back-end's message queue (ZMQ), used by both Blockbook and back-end configuration template. See note on templates below.
  • backend – Definition of back-end package, configuration and service.

    • package_name – Name of package. See convention note in build guide.
    • package_revision – Revision of package. See convention note in build guide.
    • system_user – User used to run back-end service. See convention note in build guide.
    • version – Upstream version. See convention note in build guide.
    • binary_url – URL of back-end archive.
    • verification_type – Type of back-end archive verification. Possible values are gpg, gpg-sha256, sha256.
    • verification_source – Source of sign/checksum of back-end archive.
    • extract_command – Command to extract back-end archive. It is required to extract content of archive to backend directory.
    • exclude_files – List of files from back-end archive to exclude. Some files are not required for server deployment, some binaries have unnecessary dependencies, so it is good idea to extract these files from output package. Note that paths are relative to backend directory where archive is extracted.
    • exec_command_template – Template of command to execute back-end node daemon. Every back-end node daemon has its service that is managed by systemd. Template is evaluated to ExecStart option in Service section of service unit. See note on templates below.
    • logrotate_files_template – Template that define log files rotated by logrotate daemon. See note on templates below.
    • postinst_script_template – Additional steps in postinst script. See ZCash definition for more information.
    • service_type – Type of service. Services that daemonize must have forking type and write their PID to PIDFile. Services that don't support daemonization must have simple type. See examples above.
    • service_additional_params_template – Additional parameters in service unit. See ZCash definition for more information.
    • protect_memory – Enables MemoryDenyWriteExecute option in service unit if true.
    • mainnet – Set false for testnet back-end.
    • config_file – Name of template of back-end configuration file. Templates are defined in build/backend/config. For Bitcoin-like coins it is not necessary to add extra template, most options can be added via additional_params. For coins that don't require configuration option should be empty (e.g. Ethereum).
    • additional_params – Object of extra parameters that are added to back-end configuration file as key=value pairs. Exception is addnode key that contains list of nodes that is expanded as addnode=item lines.
  • blockbook – Definition of Blockbook package, configuration and service.

    • package_name – Name of package. See convention note in the build guide.
    • system_user – User used to run Blockbook service. See convention note in the build guide.
    • internal_binding_template – Template for -internal parameter. See note on templates below.
    • public_binding_template – Template for -public parameter. See note on templates below.
    • explorer_url – URL of blockchain explorer. Leave empty for internal explorer.
    • additional_params – Additional params of exec command (see Dogecoin definition).
    • block_chain – Configuration of BlockChain type that ensures communication with back-end service. All options must be tweaked for each individual coin separely.
      • parse – Use binary parser for block decoding if true else call verbose back-end RPC method that returns JSON. Note that verbose method is slow and not every coin support it. However there are coin implementations that don't support binary parsing (e.g. ZCash).
      • mempool_workers – Number of workers for BitcoinType mempool.
      • mempool_sub_workers – Number of subworkers for BitcoinType mempool.
      • block_addresses_to_keep – Number of blocks that are to be kept in blockaddresses column.
      • additional_params – Object of coin-specific params.
  • meta – Common package metadata.

    • package_maintainer – Full name of package maintainer.
    • package_maintainer_email – E-mail of package maintainer.

Go template evaluation note

We use text/template package to generate package definitions and configuration files. Some options in coin definition are also templates and are executed inside base template. Use {{.path}} syntax to refer values in coin definition, where .path can be for example .Blockbook.BlockChain.Parse. Go uses CamelCase notation so references inside templates as well. Note that dot at the beginning is mandatory. Go template syntax is fully documented here.

Built-in text

Since Blockbook is an open-source project and we don't prevent anybody from running independent instances, it is possible to alter built-in text that is specific for Trezor. Text fields that could be updated are:

  • about – A note about instance shown on the Application status page and returned by an API.
  • tos_link – A link to Terms of service shown as the footer on the Explorer pages.

Text data are stored as plain text files in build/text directory and are embedded to binary during build. A change of theese files is mean for a private purpose and PRs that would update them won't be accepted.

You can’t perform that action at this time.