Skip to content

Client Configuration

Let's look at the client configuration options.

Client configuration example
json
{
  "PUBLIC_KEY": "ed01207233BFC89DCBD68C19FDE6CE6158225298EC1131B6A130D1AEB454C1AB5183C0",
  "PRIVATE_KEY": {
    "digest_function": "ed25519",
    "payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
  },
  "ACCOUNT_ID": "alice@wonderland",
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
  "TORII_API_URL": "http://127.0.0.1:8080/",
  "TORII_TELEMETRY_URL": "http://127.0.0.1:8180/",
  "TRANSACTION_TIME_TO_LIVE_MS": 100000,
  "TRANSACTION_STATUS_TIMEOUT_MS": 15000,
  "TRANSACTION_LIMITS": {
    "max_instruction_number": 4096,
    "max_wasm_size_bytes": 4194304
  },
  "ADD_TRANSACTION_NONCE": false
}

Generation

You can use kagami to generate the default client configuration:

bash
$ kagami config client > client-config.json

Public and Private Keys

The configs/client_cli/config.json client configuration file should contain a pair of the user's public PUBLIC_KEY and private PRIVATE_KEY cryptographic keys for their account's ACCOUNT_ID.

For details on cryptographic keys, see Public Key Cryptography.

User account

The ACCOUNT_ID should be self-explanatory. The only thing you need to worry about is that the account must already exist in the blockchain. In other words, the account you provide here should already be registered.

Note

Iroha is case-sensitive, meaning that Alice@wonderland is different from alice@wonderland. It should go without saying that alice@wonderland is not the same as alice@looking_glass either, since these accounts belong to different domains, wonderland and looking_glass.

Basic Authentication Credentials

The idea of basic authentication credentials is to provide the access control using a web server with a reverse proxy like Nginx while these credentials are ignored by the Iroha peers.

The login and password will be filled by the client and used for the Authorization HTTP header.

Use this style of configuration to provide the basic authentication credentials (login and password):

json
  "BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },

Iroha Public Addresses

TORII is the module in charge of handling incoming and outgoing connections. For client configuration, you can set up two addresses: TORII_API_URL and TORII_TELEMETRY_URL.

TORII_API_URL

First, the TORII_API_URL is the same as TORII API_URL in the peer configuration. This is the module responsible for handling incoming and outgoing connections. You should also add the prefix http:// or (preferably) https:// to the address. For example:

json
"TORII_API_URL": "http://127.0.0.1:8080"

TORII_TELEMETRY_URL

The TORII_TELEMETRY_URL is used to specify the prometheus endpoint address. You can set TORII_TELEMETRY_URL like this:

json
"TORII_TELEMETRY_URL": "http://127.0.0.1:8180"

A GET request to the 127.0.0.1:8180/status will give you a JSON-encoded representation of the top-level metrics, while a GET request to 127.0.0.1:8180/metrics will give you a (somewhat verbose) list of all available metrics gathered in Iroha. You might want to change this if you're having trouble gathering metrics using prometheus.

INFO

Learn how to monitor Iroha performance using prometheus.

Transaction Limits

You can specify the transaction limits that each transaction must adhere to: the maximum number of instructions and the maximum size of a WASM blob (in bytes). For example:

json
{
  "max_instruction_number": 4096,
  "max_wasm_size_bytes": 4194304
}

Transaction TTL and Timeout

Configure the time-to-live (TTL) for transactions and the timeout to wait for the status. Both values have to be provided in milliseconds. For example:

json
"TRANSACTION_TIME_TO_LIVE_MS": 100000,
"TRANSACTION_STATUS_TIMEOUT_MS": 15000,

Transaction Nonce

If you set ADD_TRANSACTION_NONCE to true, Iroha will create different hashes for transactions that occur repeatedly and simultaneously.